Rendering

[drwelby]

Place to dump discussion of color representation and rendering

[drwelby]

Existing standards around rendering maps or graphs

• TIFF palette
• ESRI colormap (text file version of TIFF palette)
• SLD: https://www.ogc.org/standards/sld
• MapServer mapfile STYLE: https://mapserver.org/mapfile/style.html
• Mapnik XML: https://github.com/mapnik/mapnik/wiki/XMLConfigReference
• CartoCSS: https://github.com/mapbox/carto
• Mapbox GL JS Style Specification: https://docs.mapbox.com/mapbox-gl-js/style-spec/
• MatPlotLib Colors: https://matplotlib.org/stable/api/colors_api.html
• Plotly
• Seaborn
• D3 Scales

[drwelby]

Given the wide variety of already established map style files, should we instead encourage linking to a style file as an asset?

[drwelby]

Data classes versus rendered classes

In pseudocode, how to handle different intents:

Classed data values:

[
  {"values": [1], "name": "Forest", "color": "green"},
  {"values": [2], "name": "Grassland", "color": "green"},
  {"values": [3], "name": "Water", "color": "blue"}
]

versus simplified rendering as

[
  {"values": [1,2], "name": "Vegetation", "color": "green"},
  {"values": [3], "name": "Water", "color": "blue"}
]

[m-mohr]

Great overview, thanks.
Yes, I think for advanced use cases I'd say we should link to existing standards. Is there a relatively simple JSON-based one that we could recommend?
For simple legend visulisations I could see that we add color or so but clearly state how advanced use cases should be tackled (instead of extending the extension).

[drwelby]

Initially I was against any styling information in classification metadata, following the idea of separation of structure and presentation.

However, recently in working with ingesting STAC to output QGIS layer files, I realized that absent styling information layer objects will use default palettes. This means that different classes in different assets can look identical, as well as common associations (blue for water) can end up being used for "dry" classes.

But if we wander too far into styling we will get lost with just the variations in defining fills versus outlines, opacity, etc. So I think to keep things simple and explicit, we should just have color, or possibly even color-hint, defined as "A reasonable color for rendering the data. This color defines the point, line, or pixel color, and for polygons defines the fill".

[cholmes]

I think I like the idea of color-hint, to help make it clear we're not endorsing this as 'real' styling. More like 'if there's not any style information then this is a good thing to use'.

[cholmes]

I agree with @m-mohr that we describe links to one solid json one that we recommend. If there's not a great single candidate then perhaps to 2 or 3. I think mapbox gl style is the leading json one... I've not actually used it much though.

[m-mohr]

I think this is reasonably defined now, I updated the description a bit by including the proposal from @drwelby ...