Dataset spatial coverage

[charlesvardeman]

This is a followup from https://github.com/earthcubearchitecture-project418/p418Vocabulary#describing-a-datasets-spatial-coverage topic. Specification of spatial geometries as Linked Data has several approaches, that I think (but could be wrong) are not necessarily compatible. The OGC ELFIE draft technical report states:

"GeoJSON-LD [http://geojson.org/geojson-ld/] was seen as a logical solution, but as described in the outstanding issues for GeoJSON-LD, nested GeoJSON coordinate arrays are not supported by JSON- LD parsers. Additionally, the schema.org geometry schema was seen as under specified in that among other reasons, it does not provide a default coordinate reference system or a mechanism to declare one. For this reason, the GeoSPARQL well known text format was included providing a precise and JSON-LD compatible geometry format. However, provided the technical limitations listed below, if some logical assumptions are made for the use of schema.org geometry (schema:GeoShape [https://schema.org/GeoShape]), it can be used to satisfy the basic geometry preview use case with significantly lower technical overhead than support for the full well known text standard. Further work should look more closely at this issue in an attempt to reconcile and provide guidance."

I think some of this is resolved in the proposed JSON-LD 1.1 with "bbox": {"@container": "@list"} that creates ordered arrays. The alternative used by GeoSPARQL and several OGC projects is to use WKT string representations which work will with linked data tools (spatial extensions in triple stores) but break web-based toolsets like leaflet and openlayers. Although there are workarounds by adding wkt string to geojson translators in javascript code.

[lewismc]

Hi @charlesvardeman thanks for logging this. Are you making any specific suggestion here? This is something we obviously need to get correct and I am not aware of what is essentially wrong at the moment if anything.

Regarding the latter portion of your comment

...but break web-based toolsets like leaflet and openlayers

This is certainly something we should consider. If you take the following landing page as an example, the Map displaying the spatial coverage could just as easily be created with Leaflet or similar. Thanks for bringing this up.

[charlesvardeman]

So, I've thought about this a bit over the last week and the suggestions I would have is in the form of adding an issues(otherwise known as things that confuse Chuck)/best practices document and point at other best practices docs like data on the web, spatial data on the web, OGC Testbed 12 JSON and GeoJSON User Guide, Building JSON-LD APIs Best Practices etc. The other suggestion is to use ESIP to poke/prod/cajole schema.org/OGC/etc to help reconcile issues.

From the geometry specification issue, right now the only real option might be to include multiple geometry definitions like:

# This is only an example and probably not syntatically correct.
{
 "@context": [
  "https://opengeospatial.github.io/ELFIE/json-ld/elf.jsonld",
  "https://opengeospatial.github.io/ELFIE/json-ld/hyf.jsonld",
  {
   "gsp": "http://www.opengeospatial.org/standards/geosparql/",
    "geojson": "https://purl.org/geojson/vocab#",
    "coordinates": {
        "@id": "geojson:coordinates",
        "@container" : "@list",
        "@values" : { 
           "@type" : "geojson:Coordinate",
           "@container" : "@set",
           "@values" : [
               {"@type" : "xsd:double", "@id":"geo:longitude"},
               {"@type" : "xsd:double", "@id":"geo:latitude"}
           ]
        }
     }
  }
 ],
"geo": {
  "@type": "schema:GeoCoordinates",
  "schema:latitude": 43.2022,
  "schema:longitude": -89.5302
 },
 "gsp:hasGeometry": {
  "@type": "gsp:Geometry",
  "gsp:asWKT": "POINT (-89.53022 43.20225)"
 },
"@graph" : [{
   "@id" : "geojson:Point",
    "coordinates" : [
         -89.53022
          43.20225
    ]
  }]
}

I think representing dataset bounding box information with multiple geometry specifications makes sense because I want search engines to discover the geometry and I might want to query via geosparql. I would then probably point to a "dataset.geojsonld" file that has only one geometry specification, and most likely in geojsonld (or covjson) using JSON-LD 1.1 since it can be converted to RDF if you really, really want to and it can (hopefully) also be consumed by standard web map tools like leaflet and openlayers. Hopefully, things like covjson can also be updated for the JSON-LD 1.1 spec.

[ashepherd]

If there's a vocabulary that does geospatial well, we can publish our own context with an update to schema:spatialCoverage to allow valaues for that vocabulary.

@charlesvardeman , is there one you like?

[charlesvardeman]

@ashepherd I just discovered a just-published OGC engineering report that covers JSON-LD 1.1 specifications. OGC Testbed-14: Application Schemas and JSON Technologies Engineering Report. But it seems like they are still using the wkt string serialization instead of the geojson coordinates array supported by the new JSON-LD 1.1 keyword? In the Developing a JSON-LD @context section they say

However, JSON-LD cannot convert a multi-dimensional array (NOTE: this restriction has led to a feature request for JSON-LD, which is documented online). This issue has been investigated in OGC Testbed 11. The engineering report Implementing JSON/GeoJSON in an OGC Standard ([8]), section 7.2., describes the issue in more detail. A reasonable solution for the issue is presented in chapter 7.5 of the ER: handle GeoJSON geometries by converting them to Well Known Text (WKT) as defined by ISO 19125-1, which is one of the two serializations supported by OGC GeoSPARQL. Listing 13 shows what the feature collection would look like after such a transformation. When transforming a GeoJSON geometry to a JSON object that contains WKT, some details need to be considered:

But then go on to talk about new JSON-LD 1.1 keywords. Section 6.3.2 talks about handling geometry but isn't that helpful in deciding the best options.

Sigh

[ashepherd]

An attempt at adding other representations of a spatial coverage:

{
  "@context": "http://schema.org/",
  "@type": "Dataset",
  "name": "XYZ",
  ...
  "spatialCoverage": {
    "@type": "Place",
    "geo": {
       "@type": "GeoShape",
       ...
     },
     "additionalProperty": [
        {
          "@type": "PropertyValue",
          "additionalType": "http://www.wikidata.org/entity/Q161779",
          "name": "Spatial Reference System for Dataset: XYZ",
          "propertyID": "SRS",
          "value": "http://www.opengis.net/def/crs/OGC/1.3/CRS84",
        },{
          "@type": "PropertyValue",
          "additionalType": "http://www.wikidata.org/entity/Q4018860",
          "name": "Well-Known Text for Dataset: XYZ",
          "propertyID": "WKT",
          "value": "POLYGON ((-75.8183 -68.4817, -68.5033 -68.4817, -68.5033 -65.08, -75.8183 -65.08, -75.8183 -68.4817))",
        }
      ]
    }
}

[charlesvardeman]

Interesting discussion as part of the WFS 3.0 work. Looks like the idea is to assume a CRS84 as a default but provide options for other cases. Particularly 3D data that includes elevation. https://github.com/opengeospatial/WFS_FES/issues/233

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.