The spatial coverage of datasets is not always specified by using location URIs or values from location code lists. Another common approach is to denote the relevant area by using geographic coordinates. This is the case of INSPIRE metadata, where spatial coverage is specified by a geographic bounding box - i.e., a rectangle delimiting the relevant area.
It may be possible to map such "geometry" to one or more named places (and then to the corresponding location URIs or code list values), but this may require increasing the approximation already implicit in a bounding box.
Moreover, the geometry-based approach can be effectively re-used to support cross-border and cross-sector spatial queries, as well as to provide a graphical representation of the spatial coverage of a dataset on a map. Notably, such features are currently supported not only by geoportals but also in general purpose open data portals. A typical example is CKAN, its geospatial extension [1], and the one developed by Ordnance Survey [2].
For these reasons, the WG may consider allowing spatial coverage to be specified as a geometry, at least if this approach is used in the original metadata.
- http://ckan.org/features/geospatial/
- http://www.geovation.org.uk/ordnance-survey-uk-location-programme-and-cabinet-office-develop-map-based-search-tool-for-data-gov-uk-and-release-the-code-as-open-source/
Comments
We could add a note to section 9 that geographic location may be identified either by a URI from a controlled vocabulary (which vocabulary is to be decided) or by geo-coordinates.
Which geo vocabulary would you recommend? Maybe W3C's Basic Geo (WGS84 lat/long) Vocabulary http://www.w3.org/2003/01/geo/? Are there others?
We have used a combinaison of Dublin core with the dcterms:location field pointing to a URI provided to the french equivalent of the Ordnance Survey and the locn vocabulary in order to describe the dataset's bounding box
<dcterms:location about="http://data.ign.fr/id/geofla/departement/33">
<locn:geographicIdentifier>http://data.ign.fr/id/geofla/departement/33</locn:geographicIdentifier&…;
<locn:geographicName>GIRONDE</locn:geographicName>
<locn:Geometry><ogc:Polygon><ogc:asWKT rdf:datatype="ocg:WKTLiteral">
<http://www.opengis.net/def/crs/OGC/1.3/CRS84> Polygon(
(
-1.26156091294 45.5731138631
0.315055728326 45.5731138631,
0.315055728326 44.194016671,
-1.26156091294 44.194016671,
-1.26156091294 45.5731138631
)
)
</ogc:asWKT></ogc:Polygon></locn:Geometry>
</dcterms:location>
I know I have a conflict of interest here, but I would suggest recommending the use of the Location Core Vocabulary [1] (also mentioned by Pascal in his example), since it has been designed to be as flexible as possible in terms of how a location is specified, also when using geometries (basically, it allows the re-use of other vocabularies, as W3C Geo or schema.org, as well as syntax encoding schemes - e.g., WKT, GML, KML, GeoJSON).
It is also worth noting that the Location CV, developed in the framework of ISA Action 1.1, has been contributed to W3C [2], and it is now a work item of the W3C Community Group on Locations and Addresses (LOCADD) [3]. This means that, if we have any specific issues / requirements, they may be submitted to the LOCADD CG. Of course, it will be up to the LOCADD CG to decide whether to address them or not by revising / extending the Location CV.
About the specific issue of how to represent / encode a geometry, the options we have may vary depending on the type of geometric objects we would like to support. Reaching an agreement on this can help identify an appropriate solution.
The proposed resolution is to add a note to the dct:spatial in section 7.1.2 and 7.2.2 that spatial coverage can be represented either by a term from a controlled vocabulary (referencing section 9) or with a description, e.g. with geographic coordinates. In the latter case the use of the Location Core Vocabulary is recommended.
This is a nice use case. I propose to add the followign user scenario:
Pavel works for an environmental agency in Croatia. He wants to obtain an overview of upstream industrial activity along the river Danube in Germany, Austria, Slovakia, and Hungary.
Pavel nagivates to the data portal of his preference (e.g. the INSPIRE geoportal or a Czech data portal), enters a search keyword ‘industry’ in Czech, draws the bounding box of the area of interest to him and is able to retrieve multiple datasets that originate from different countries and that have been catalogued on different data portals with descriptions in different languages. Pavel can further refine his search by adjusting geographic coverage or filtering on the theme, spatial coverage (geographic names), temporal coverage, licence, etc of the datasets in the search results. The search results may contain a graphical representation of the spatial coverage on a map.
This has been included in Draft 2 (section 7.1.3 and 7.2.3)