Re: Best Practice for encoding spatial coverage

Hi, Frans.

> [snip]
>
> By the way, following the information on the web about alignment of INSPIRE
> metadata with DCAT, I came across this example of dataset metadata that
> includes a stament on spatial extent:
>
>     dcterms:spatial [ a dcterms:Location ;
>             locn:geometry "<gml:Envelope
> srsName=\"http://www.opengis.net/def/EPSG/0/4326\"><gml:lowerCorner>-10.58
> 34.56</gml:lowerCorner><gml:upperCorner>34.59
> 70.09</gml:upperCorner></gml:Envelope>"^^<http://www.opengis.net/rdf#GMLLiteral>
> ] ;
>
> In this example, a dcterms:Location is described as a GML fragment. While
> this conforms with current W3C and OGC standards, from the point of view of
> the web developer this not optimal. First, somehow the GML code needs to be
> recognised as GML code and secondly the GML code needs to be parsed in order
> to obtain the required numbers.

This approach has been revised in the framework of GeoDCAT-AP [1].

The option we would have liked to adopt was about a specific RDF
property for bboxes, with a simple encoding (e.g., lower corner, upper
corner). However, since there's currently no best practice, the
decision was to recommend WKT or GML (as per GeoSPARQL), but
supporting the possibility of using multiple encodings. The used
property is still locn:geometry.

The motivation was that there's no reason why we should prevent people
from using different encodings, but we need a recommended one to
ensure interoperability. The candidates were WKT, GML and GeoJSON. WKT
got the majority of the votes, followed by GML, and then GeoJSON.

Based on that, the XSLT [2] implementing the alignments defined in
GeoDCAT-AP provides both WKT and GML (i.e., both the recommended
ones), plus GeoJSON - e.g.:

...
  <dct:spatial rdf:parseType="Resource">
    <locn:geometry
rdf:datatype="http://www.opengis.net/ont/geosparql#wktLiteral"><![CDATA[
      POLYGON((-6.41736 55.7447,2.05827 55.7447,2.05827
49.8625,-6.41736 49.8625,-6.41736 55.7447))
    ]]></locn:geometry>
    <locn:geometry
rdf:datatype="http://www.opengis.net/ont/geosparql#gmlLiteral"><![CDATA[
      <gml:Envelope srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84">
        <gml:lowerCorner>-6.41736 49.8625</gml:lowerCorner>
        <gml:upperCorner>2.05827 55.7447</gml:upperCorner>
      </gml:Envelope>
    ]]></locn:geometry>
    <locn:geometry
rdf:datatype="https://www.iana.org/assignments/media-types/application/vnd.geo+json"><![CDATA[
      {"type":"Polygon",
       "crs":{"type":"name","properties":{"name":"urn:ogc:def:crs:OGC:1.3:CRS84"}},
         "coordinates":[[[-6.41736,55.7447],[2.05827,55.7447],[2.05827,49.8625],[-6.41736,49.8625],[-6.41736,55.7447]]]
      }
    ]]></locn:geometry
  </dct:spatial
...


@All: The GeoDCAT-AP specification is going to be published shortly
for public review, and I'll take care of sending you the call for
comments, along with a summary of the open issues that may be in scope
with the SDW WG (which include, e.g., the specification of reference
systems and spatial resolution). Any feedback would be very much
appreciated.

Cheers,

Andrea

----
[1]https://joinup.ec.europa.eu/node/139283/
[2]https://webgate.ec.europa.eu/CITnet/stash/projects/ODCKAN/repos/iso-19139-to-dcat-ap/

Received on Thursday, 18 June 2015 00:44:34 UTC