RE: Geo data in JSON-LD

You will also have to carry over the restrictions on reference systems and units of measure described in http://www.w3.org/TR/geolocation-API/#coordinates_interface , but be aware that many legacy systems and data will not be in this form. And the more elements you introduce, the more opportunities for misunderstandings, particularly in relation to the (coordinate) reference system, and units of measure, unless they are explicit. For elevation a number of datums are in common use: Mean Sea Level (usually defined locally), the geoid, some isobar, (or even the centre of the earth). And feet, or even barometric pressure are used in aviation.  Similar issues with speed: mph, km/h, feet-per-second, knots, m/s are all common. Even lat/lon is an issue in some jurisdictions, where other coordinate systems are conventional, or even legally required (e.g. easting/northing is used in most, but not all, projected systems; then there are local systems like the British Grid Reference system, etc.).  

On serialization: I see that you are already aware of the discussion on the GeoJSON-LD list: https://github.com/geojson/geojson-ld/issues/28 

For the record, WKT was not introduced in GeoSPARQL, though many people will have encountered it first in that context. It was developed by OGC for Simple Features, but the best reference is probably SQL-MM. 

Simon Cox

-----Original Message-----
From: James M Snell [mailto:jasnell@gmail.com] 
Sent: Friday, 10 October 2014 4:02 AM
To: public-vocabs@w3.org Vocabs; public-socialweb@w3.org; Dan Brickley
Subject: Geo data in JSON-LD

(fyi... cross posted to public-vocabs and public-socialwb, sorry to those who receive this twice)

I'm working on use cases for expressing geo data in Activity Streams 2.0. The original thought was to leverage GeoJSON but since JSON-LD does not support GeoJSON's lists-of-lists model for coordinates, I'm looking at using the W3C Basic Geo Vocabulary
(http://www.w3.org/2003/01/geo/) for simple cases and the OpenGIS GeoSparql vocabulary (WKT) for more complex cases. I noticed that I'm not the only one considering this [see:
https://github.com/rvguha/schemaorg/issues/113] so I figured a quick sanity check discussion here would be worthwhile.

First, the simple case:

{
 "@context": [
   "http://asjsonld.mybluemix.net"
  ],
  "@type": "as:Activity",
  "verb": "post",
  "actor": {
    "@type": "urn:example:types:Person",
    "@id": "urn:example:people:joe",
    "displayName": "James M Snell",
    "location": {
      "@type": "geo:Point",
      "geo:lat": 1.23,
      "geo:long": 3.45
    }
  },
  ...
}

This case ought to be fairly straightforward. The one thing I will note, however, is that the W3C Geolocation API [http://www.w3.org/TR/geolocation-API/#position_interface] provides significantly more detail than what the Basic Geo Vocabulary is currently able to capture. I'm curious as to whether or not it would make sense to update the Basic Geo Vocabulary to include these additional data points. Specifically adding:

  geo:altitude
  geo:accuracy
  geo:altitudeAccuracy
  geo:heading
  geo:speed

For the more complex cases, using the WKT specification seems to make the most sense:

{
 "@context": [
   "http://asjsonld.mybluemix.net"
  ],
  "@type": "as:Activity",
  "verb": "post",
  "actor": {
    "@type": "urn:example:types:Person",
    "@id": "urn:example:people:joe",
    "displayName": "James M Snell",
    "location": {
      "@type": "geos:Geometry",
      "geos:asWKT": "Polygon((-83.6 34.1, -83.2 34.1, -83.2 34.5,
-83.6 34.5, -83.6 34.1))"
    }
  },
  ...
}

Seem like a sane approach to folks?

- James

Received on Thursday, 15 January 2015 06:20:09 UTC