Spatial coverage [RSC]

[jpullmann]

Spatial coverage [RSC]

Provide means to specify spatial coverage with geometries.

Related use cases: Modeling spatial coverage [ID29] 

[makxdekkers]

This is already possible using the Core Location Vocabulary that includes a class Geometry.

[makxdekkers]

Related to #82

[stijngoedertier]

I also like the use of the locn:geometry property for encoding geometries as literals. See also page 57 in GeoDCAT-AP.

[nicholascar]

I don't follow, how can locn:geometry be used? Range for dct:spatial is dct:Location and I see no locn/dct links (subclassing).

Assuming I've missed something and this can work,

locn:geometry seems allows for WKT/GML representation as per GeoSPARQL. From @stijngoedertier 's example:

locn:geometry "POLYGON((-10.58 70.09,34.59 70.09,34.59 34.56,-10.58 34.56,  -10.58 70.09))"^^gsp:wktLiteral ;

However we have more sophisticated feature/geometry handling elsewhere, like in GeoSPARQL itself which has Geometry & Feature classes. Using GeoSPARQL, a site's location in SOSA:

<http://pid.geoscience.gov.au/site/17943> a <http://vocabulary.odm2.org/samplingfeaturetype/borehole>,
    geosp:hasGeometry [ a geosp:Geometry ;
            geosp:asWKT "SRID=GDA94;POINT(137.8563726 -33.7108293)"^^geosp:wktLiteral ] .

I can't see any normative links from locn to GeoSPARQL though, only suggestions for use. Perhaps Andrea, a locn editor, can indicate the intention of locn? Otherwise, I'd be more inclined to allow the use of GeoSPARQL directly.

[stijngoedertier]

locn:geometry would be a property of a dcterms:Location, as in the examples: GeoDCAT-AP page 57 or the SDW-BP example 15. Something like:

[] a dcat:Dataset;
   dcterms:spatial [
      a dcterms:Location;
      locn:geometry "POINT(4.7173 50.8643)"^^geosparql:wktLiteral ] .

As @nicholascar suggests, this can indeed also be done directly using geosparql:hasGeometry. GeoSparql provides a normative way of representing geometries expressed as WKT or GML, although it leaves other serializations such as GeoJSON to future work.

[] a dcat:Dataset;
   dcterms:spatial [
      a dcterms:Location;
      geosparql:hasGeometry [ 
            a geosparql:Geometry ;
            geosparql:asWKT "POINT(137.8563726 -33.7108293)"^^geosparql:wktLiteral ]
] .

[rob-metalinkage]

is "coverage" the same as "the geometry"?

The definition of locn:geometry is "Associates any resource with the corresponding geometry."

DCAT may have a concept of "the" - i.e. there is a requirement that the geometry is a specific type with a specific characteristics...

There is a difference between a geometry defining and indexable extent (normal use of coverage) and for example a 3D model of a city - and certainly most geographical features having area extents. To put this in perspective, some time ago i was looking at modelling the coastline - and there are something like 26 different definitions in Australian law - so there are in fact multiple possible geometries depending on the application domain , but most significantly, if you take a large entity - such as the state of Western Australia (or even one of the indigenous land claims in the state) you get a geometry of many MB from the authoritative dataset, but any most applications would need a generalised form.

so, if you re-use a term with a broader semantics for a specific function, at some stage this needs to be declared. The qualified link to the geometry object gives you this AFAICT. You may need to specify that the dcterms:Location has the same meaning as you intend for "coverage" - or perhaps create a subclass of it with this explicit semantics. If the OWL model entails this when the subject of a dct:spatial relationship is a dcat:Dataset, then backwards compatibility is maintained with the use of dcterms:Location

[nicholascar]

From the locn documentation (https://www.w3.org/ns/locn) for the Property geometry:

:Resource locn:geometry [ 
  a sf:Point; 
  gsp:asWKT "<http://www.opengis.net/def/crs/OGC/1.3/CRS84> Point(-0.001475 51.477811)"^^gsp:wktLiteral 
] .

So, given the domain constrains of gsp:asWKT, the blank node is a gsp:Geometry as well as an sf:Point (and an sf:Geometry). The range value for locn:geometry is a locn:Geometry so, a locn:Geometry == gsp:Geometry. But there is no domain value for locn:geometry so we can't say that in this example the :Resource is equivalent to a gsp:Feature, which is what the use of gsp:geometry would make it.

[andrea-perego]

Sorry to jump in here so late.

I should probably provide a bit of context for explaining the reasons behind the design choices of locn:geometry and its use for specifying the spatial coverage of a dataset.

So, the reason why the range of locn:geometry was left open is twofold:

• We had use cases requiring the specification of a geometry directly as a literal, without using specific classes.
• We had also use cases requiring more sophisticated geometry specifications (as in GeoSPARQL). Nonetheless, at the time when LOCN was defined, there was no widely used vocabulary/approach for doing this (yes, GeoSPARQL was out, but not used across domains). So, we focussed on identifying the most used options.

Coming now to the use of locn:geometry in GeoDCAT-AP (which is more relevant here), the issue was to find out how to represent the spatial coverage from ISO 19115 records, which, in the majority of the cases, is done with a bbox.

DCAT didn't provide any guidance on this. Moreover, the GeoDCAT-AP WG re-stated the requirement of being able to directly specify the bbox as a literal. So, the choice of locn:geometry was pretty straightforward, and all discussion focussed instead on which should be the recommended geometry encoding (the most voted options being GML, WKT and GeoJSON).

The use of locn:geometry along these lines has been also documented in the W3C/OGC Spatial Data on the Web BPs - see, e.g., Example 15.

Based on the implementation experiences I'm aware of, the use of locn:geometry in this way has not raised any specific problem. Rather, the issue (that we had also when developing GeoDCAT-AP) is that there is no established practice on how to specify bboxes in RDF (and even centroids). However, as far as I can understand, working on this is not in scope of the DXWG.

BTW, this was also one of the issues discussed at length in the LOCADD CG (there's a page summarising the discussion), and then inherited by the SDWWG, but no solution has been provided.