Extending the GeoSPARQL ontology with feature style descriptions

[situx]

I have developed several tools in the last year which required me to define a feature style for certain geometry representations modelled with GeoSPARQL. I ended up defining:

• A style property which links a geo:Geometry to a style description instance with
  • point/lineString/Polygon style properties with CSS literals
  • pointImage/lineStringImage/polygonImage properties with URIs pointing to Icons or SVG definitions (SVG literals)
  • hatch: Whether to draw the geometry in a hatched style
  • lineStringImageStyle: How the image behaves in the lineString (how often it is repeated etc.)

There may be several style representations per geometry and there could be constraints attached to each of these styles which link to certain semantic classes (for now modelled as text literals by me). So there could be the possibility for reasoning eligible styles for a Geometry representation according to the data given.

What I currently do with these style representations is to downlift them to GeoJSONCSS (https://github.com/albburtsev/Leaflet.geojsonCSS) and then add them to a Leaflet view.

My questions are therefore:

• Is the GeoSPARQL ontology the right place to standardize feature style descriptions?
• Is there any other related work known to members of the group or best practices I have overlooked?

[FransKnibbe]

My experiences tell me it is generally good practice to maintain separation of concerns. In this case that goes for definition of spatial data and their depiction. Just like it is possible to separate content and presentation with HTML and CSS. So I think styling and symbolization could be bolted onto GeoSPARQL, but should better be kept in a separate vocabulary.

I have no knowledge of exiting related work, but I do like the idea of having some kind of way to define visualization styles for spatial graph data. And I think that styling GeoSPARQL data could be helped by some of the change requests in our queue. For example, having a geometry class hierarchy could help defining different styles for different geometry types. In general, the desire to have some sort of styling definitions for spatial data could be viewed as a requirement for more selectivity in geometric data. An extension of semantics for geometry will result in more ways to filter or categorize spatial data, which is useful in styling.

Also something to consider: if issue 14 is honoured, there should be no or far less difference between geometry models, making style declarations interchangeable between SVG, X3D and Simple Features for example.

[situx]

Yes, it could possibly be one of the GeoSPARQL extension vocabularies that we have talked about previously. Another aspect to be considered is that if we want to have linked data backends for OGC API Styles , then also an ontology representation of styles for spatial data is probably necessary.