Styling coverages: extension for selectors and symbolizer properties

[jerstlouis]

We should define a conceptual model, logical model and encodings extension for styling coverages.

Support selection based on range values, defining RGBA channels output values (e.g. using band arithmetic).

[chris-little]

@jerstlouis Yes, but I would like some use cases documented to support and test any abstraction. I think talking about RGBA is too implementation specific. Would you include Look Up Tables in the model i.e. any discretization of the coverage range then mapped to some display/symbol/rendering. And what about a coverage with a vector range (a wind or ocean current field)?

[ebocher]

Hi all, Let me share with you a draft we wrote several centuries ago ;-) about style coverage. To add fuel on the discussion.

RasterStyle paper ideas.docx

Best Erwan

[chris-little]

@ebocher @jerstlouis I think that paper is to too closely tied to the notion grid=raster=image rather than data = gridded. As well as the vector data example that I mention, we also have data that is a tensor at every grid point. E.g. wind stress, useful for forecasting wave heights or risks to buildings or impact on aircraft. And where do contours, streamlines, trajectories fit into the portrayal schemes?

[ebocher]

@chris-little

I think that paper is to too closely tied to the notion grid=raster=image rather than data = gridded

Sure. This is the idea.

Can you share some modelling ideas you have in mind ?

[jerstlouis]

Thank you for identifying good use cases out of our comfort box @chris-little . I think we should definitely give thoughts to these. However we may start by first developing extensions for more widespread use cases, keeping in mind that the whole new portrayal framework is fully extensible and should make it easy to define extensions for additional use cases.

[chris-little]

@jerstlouis @ebocher I am happy to kick the tensor use cases and 3+D use cases down the road in the short term, but I think the 2D vector cases for wind/currents/traffic/heatflow/migration/etc are very common, so considering at the same time as scalar properties should help expose some hidden assumptions or biases in the traditional approach.

[jerstlouis]

@chris-little Let's also consider that use case at the same time, but I think it would belong in a separate extension or at least a separate conformance class than the capability to generate an RGB(A) output from a coverage.

I think it could leverage the markers property described in #11, by associating a transform orientation with properties or a function that derives those properties from others. Perhaps it could also be possible to specify the desired density for interpolating or calculation those values. In this sense it would be closer to the vector feature symbolizer, rendering the coverage much like a MultiPoint geometry.

Example (for a coverage with ID _winddirection and a field named direction:

#wind_direction
{
   markers = [ Image { "windIcon.svg" } ];
   transform = { angle = direction };
}

[chris-little]

@jerstlouis Sounds good.

I am also assuming that RGB(A) is a shorthand for an abstract colour space, which could be one of many implementations, such as HSV, CIE, CMYK, etc RGB in practice is usually a quite limited triangular subset of the full gamut of CIE.