In GeoBlacklight v3, there was a simple single-valued field for tracking the "geometry type" of a layer that determined what icon to use. This helped distinguish between e.g. polygon data and point data:
In GeoBlacklight v4, there are two fields that describe the type of a layer, and both are multi-valued: the more general resource class and more specific resource type. Both have controlled vocabularies; note that resource type actually has two separate controlled vocabularies (one for maps and one for geo data).
The current implementation just uses the first value from resource class to decide what icon to use. This means all geo data is lumped into one "Datasets" category, so an index map appears no different from a raster:
Similarly, when looking at the relation box on collection pages, all of the members of the collection use a generic "leaf" icon instead of the one that indicates what data type they are:
Ideally, we could get some of the old behavior back, where things like polygon data and line data are distinguished.
Implementation ideas
if the item has a resource class of "Collections", "Maps", "Other", etc. just use the current behavior.
if the item has a resource class of "Datasets", we need to look at the resource type.
"Polygon data" -> polygon icon
"Line data" -> line icon
"Point data" -> point icon
"Raster data" -> raster icon
other stuff...see what's available in GeoBlacklight?
Places to look
the header_icons partial is responsible for rendering the three icons per record (lock, institution icon, and layer type icon)
the geoblacklight_helper is ultimately what gets called to get an icon or use a default if it can't find one
there is a setting called RELATIONSHIPS_SHOWN that determines how the relationships sidebar/box gets rendered; this determines what icon is used when e.g. looking at the listing of items in a collection on the collection's page.
to get resource type information available at the time we render those relationship sidebars (and thus display a specific icon and not the generic "leaf" or "collection" icon), we would need to update/override the relevant relation response classes, like Ancestor, so that we ask solr to return that field in the relation query. then we can use it to render the icon. (this is what the setting USE_GEOM_FOR_RELATIONS_ICON did in gblv3, but it's broken in v4).
Note: this could be accomplished in GeoBlacklight, or drafted in Earthworks and then ported to GeoBlacklight later. See related issue https://github.com/geoblacklight/geoblacklight/issues/1041.
The problem
In GeoBlacklight v3, there was a simple single-valued field for tracking the "geometry type" of a layer that determined what icon to use. This helped distinguish between e.g. polygon data and point data:
In GeoBlacklight v4, there are two fields that describe the type of a layer, and both are multi-valued: the more general resource class and more specific resource type. Both have controlled vocabularies; note that resource type actually has two separate controlled vocabularies (one for maps and one for geo data).
The current implementation just uses the first value from resource class to decide what icon to use. This means all geo data is lumped into one "Datasets" category, so an index map appears no different from a raster:
Similarly, when looking at the relation box on collection pages, all of the members of the collection use a generic "leaf" icon instead of the one that indicates what data type they are:
Ideally, we could get some of the old behavior back, where things like polygon data and line data are distinguished.
Implementation ideas
Places to look
header_iconspartial is responsible for rendering the three icons per record (lock, institution icon, and layer type icon)geoblacklight_helperis ultimately what gets called to get an icon or use a default if it can't find oneRELATIONSHIPS_SHOWNthat determines how the relationships sidebar/box gets rendered; this determines what icon is used when e.g. looking at the listing of items in a collection on the collection's page.Ancestor, so that we ask solr to return that field in the relation query. then we can use it to render the icon. (this is what the settingUSE_GEOM_FOR_RELATIONS_ICONdid in gblv3, but it's broken in v4).