The issue under discussion concerns which should be the preferable encoding(s) for a geometry - in particular, for a bounding box - taking into account its possible uses and common practices in existing data portals and triple stores.

Alternatives to GML (proposed in the current draft) can be, e.g.:

• WKT (Well-Known Text): it offers the most compact textual encoding for a geometry, and it is supported by a number of triple stored (even those not supporting GeoSPARQL).
• GeoJSON: this encoding can be directly consumed by Web applications and supported by some data portals. E.g., CKAN has a geospatial extension able to use GeoJSON to support spatial search and visualisation.

It is worth noting that in (Geo)DCAT-AP it is possible to specify the bounding box of a dataset by using multiple geometry encodings. So, GeoDCAT-AP could leave to data providers the choice of the enconding(s) they would like to use, but recommending, for interoperability reasons, that at least a given geometry encoding (e.g., GML, WKT, GeoJSON) is also made available.

There was a short discussion on this during the 2nd WG meeting (see the minutes).

If multiple geometry encodings  (e.g. GML, WKT, GeoJSON, etc) are allowed, it would be good to always indicate which encoding is used, so that geometry literals can be easily parsed by machines.

This is possible in GeoSPARQL by using typed literals (the RDF data types ogc:gmlLiteral and ogc:wktLiteral), as illustrated in the Core Location Vocabulary (there seems to be one typo: the data types ogc:gmlLiteral and ogc:wktLiteral start with a lower case, this typo seems to have also slipped into our specs).

Is there an RDF data type for GeoJSON or KML?

In case appropriate XML Schema / RDF datatypes are missing, an option would be to use IANA media type URLs (if available). E.g.:

• GeoJSON: http://www.iana.org/assignments/media-types/application/vnd.geo+json
• KML: http://www.iana.org/assignments/media-types/application/vnd.google-earth.kml+xml

Andrea Perego opened a discussion about this on the mailing list:

http://joinup.ec.europa.eu/mailman/archives/dcat_application_profile-geo/2015-May/thread.html

"I would like to ask your vote for one of the
following options (e.g., just type "+1 to option X"):

A. Geometries can be provided in multiple encodings, but at least one of the following must be made available: GML, WKT, GeoJSON
B. Geometries can be provided in multiple encodings, but at least GML must be made available
C. Geometries can be provided in multiple encodings, but at least WKT must be made available
D. Geometries can be provided in multiple encodings, but at least GeoJSON must be made available"

Via the mailing list, the following votes came in... and revised proposal was made.

http://joinup.ec.europa.eu/mailman/archives/dcat_application_profile-geo/2015-May/000066.html

Andrea Perego andrea.perego at jrc.ec.europa.eu
Mon May 18 01:34:24 CEST 2015

• Previous message: [Geo-DCAT-AP] GeoDCAT-AP 4th WG Virtual Meeting >> 20 May 2015 14:00 CEST + working group draft 4
• Next message: [Geo-DCAT-AP] Revision #1 to recommended encoding(s) for geometries / bounding boxes
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Dear colleagues,

Based on your feedback to the relevant email threads [1,2], the
situation is as follows:

0 votes for option A ("use GML, WKT, and/or GeoJSON")

2 votes for option B ("use GML")

4 votes for option C ("use WKT")

0 votes for option D ("use GeoJSON")


Since we haven't reached an agreement on the preferred encoding to be
recommended, the revised proposal is as follows:

E. Geometries can be provided in any, and possibly multiple,
encodings, but at least one of the following must be made available:
WKT, GML

This basically aligns GeoDCAT-AP with GeoSPARQL, where WKT and GML are
the supported encodings.

Always following GeoSPARQL, CRS84 (and not EPSG:4326) will be the
default CRS for the specified geometry encodings. This implies that
axis order will be lon / lat. On this, see [3].


The XSLT [4] has been revised accordingly.


We have still time to change the proposal, if need be, before we go
for public review. So, if you have any comments, please post them to
the mailing list.

Thanks!

Andrea

----
[1]http://joinup.ec.europa.eu/mailman/archives/dcat_application_profile-geo/2015-May/000052.html
[2]http://joinup.ec.europa.eu/mailman/archives/dcat_application_profile-geo/2015-May/000053.html
[3]http://joinup.ec.europa.eu/mailman/archives/dcat_application_profile-geo/2015-May/000064.html
[4]https://webgate.ec.europa.eu/CITnet/stash/projects/ODCKAN/repos/iso-19139-to-dcat-ap/

During the 4th WG meeting of 20 May 2015, it was decided by vote that

• Geometries can be provided in any, and possibly multiple, encodings, but at least one of the following must be made available: WKT or GML.
• The default coordinate reference system will be CRS84.

There is an explanation of the decision taken in the last version of the GeoDCAT-AP specifications. This can be completed with the issue about mapping geographic identifiers for spatial coverage:

In the core profile of ISO 18115, spatial coverage can be specified either with a bounding box (a geometry) or a geographic identifier. INSPIRE is more restrictive, in that it requires to use a bounding box

Based on that, GeoDCAT-AP models spatial coverage as follows:

• Bounding box: When the area corresponding to the spatial coverage is denoted by a geometry, as in INSPIRE, DCAT-AP recommends the use of the Core Location Vocabulary, where this is done by using property locn:geometry, having as range a geometry specified as
  • ​a URI - e.g., by using the geo URI scheme (IET RFC-5870), or a geohash URI;
  • a syntax encoding scheme - e.g., geohashes, WKT (ISO-19125), GML, KML, GeoJSON; or
  • a semantic representation - using vocabularies like W3C Lat/long or schema.org.
    
    It is worth noting that currently there is no agreement on a preferred format to be used in RDF for the representation of geometries. Geometries can be provided in any, and possibly multiple, encodings, but at least one of the following must be made available: WKT or GML. An additional requirement concerns the coordinate reference system (CRS) used, which may vary on a country or territory basis. Following GeoSPARQL, the CRS must be always specified in the WKT endcoding when it is different from CRS84 (WGS84, with axis order longitude / latitude). Summarising:
  • Geometries can be provided in multiple encodings, but at least one of the following must be made available: GML and WKT.
  • The coordinate reference system used must be always specified when different from CRS84.
  • For GML and WKT, the CRS must be specified as defined in GeoSPARQL.

​The following example shows how to specify the spatial coverage.

​

# Resource metadata in GeoDCAT-AP using a geographic bounding box. This example uses multiple encodings, namely, the
# recommended ones (WKT and GML), plus GeoJSON. To denote the datatype of the GeoJSON literal, the URL of the corresponding
# IANA media type.
[] dct:spatial [ a dct:Location ;
       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 ;
       locn:geometry "<gml:Envelope srsName=\"http://www.opengis.net/def/crs/OGC/1.3/CRS84\">
                        <gml:lowerCorner>34.56 -10.58</gml:lowerCorner>
                        <gml:upperCorner>70.09 34.59</gml:upperCorner>
                      </gml:Envelope>"^^gsp:gmlLiteral ] ;
       locn:geometry "{\"type\":\"Polygon\",\"crs\":{\"type\":\"name\",\"properties\":{\"name\":\"urn:ogc:def:crs:OGC:1.3:CRS84\"}},
                        \"coordinates\":[[[-10.58,70.09],[34.59,70.09],[34.59,34.56],[-10.58,34.56],[-10.58,70.09]]]
                      }"^^<https://www.iana.org/assignments/media-types/application/vnd.geo+json> ].
# Resource metadata in GeoDCAT-AP using a geographic identifier
#If a URI is used for the geographic identifier (recommended)
[]  dct:spatial <http://publications.europa.eu/resource/authority/country/NLD>.
#If no URI is used for the geographic identifier
[]    dct:spatial [
        skos:preflabel "Netherlands"@en;
       skos:prefLabel "Nederland"@nl;
       skos:inScheme [
           dct:title "Countries Authority Table"@en;
           dct:modified "2009-01-01"^^xsd:date
           ]      
       ].

<!-- Resource metadata in ISO19139 using a geographic bounding box -->
<gmd:MD_Metadata>
     ...
     <gmd:identificationInfo>
        <gmd:MD_DataIdentification>
             <gmd:extent>
                 <gmd:EX_Extent>
                 <gmd:geographicElement>
                      <gmd:EX_GeographicBoundingBox>
                           <gmd:extentTypeCode>
                               <gco:Boolean>true</gco:Boolean>
                           </gmd:extentTypeCode>
                           <gmd:westBoundLongitude>
                               <gco:Decimal>-9.227701</gco:Decimal>
                           </gmd:westBoundLongitude>
                           <gmd:eastBoundLongitude>
                               <gco:Decimal>2.687637</gco:Decimal>
                           </gmd:eastBoundLongitude>
                           <gmd:southBoundLatitude>
                               <gco:Decimal>49.83726</gco:Decimal>
                           </gmd:southBoundLatitude>
                           <gmd:northBoundLatitude>
                               <gco:Decimal>60.850441</gco:Decimal>
                           </gmd:northBoundLatitude>
                      </gmd:EX_GeographicBoundingBox>
                      </gmd:geographicElement>
                 </gmd:EX_Extent>
             </gmd:extent>
        </gmd:MD_DataIdentification>
    </gmd:identificationInfo>
     ...
</gmd:MD_Metadata>