Json-LD instances test : use Schema.org prefix for latitude and longitude.

[afeliachi]

No aliases are declared in the GeoJSON context for latitude and longitude properties. Always check if the Alias is defined in the context, use the proper prefix if the alias does not exist. Ex : https://opengeospatial.github.io/ELFIE/usgs/huc12boundary/uswb/010300032404 "latitude": 45.0742, "longitude": -69.8528 Latitude and longitude are not declared : should be declared or "geojson:longitude" "geojson:latitude" should be used instead.

[dblodgett-usgs]

Unfortunately, latitude and longitude are not defined by the geojson namespace. https://purl.org/geojson/vocab# doesn't contain latitude or longitude.
Doing some snooping at http://geojson.org/geojson-ld/ -- I see this:

Nested GeoJSON coordinate arrays are incompatible with the processing model of JSON-LD 1.0. There are no current best practices for addressing this issue. Applications that process GeoJSON as JSON-LD using the GeoJSON-LD 1.0 context must take extra steps not defined here to ensure that geometric coordinates are processed appropriately.

This leaves us with two options -- 1) break the rules and point out that this issue needs to be solved or 2) scale back our ambition to encode geojson geometries directly in our json-ld documents by linking to them directly instead.

I had already been considering doing #2. @abhritchie @jkreft-usgs -- you two have been the most active in this discussion, what say you?

[afeliachi]

My bad. I meant to say schema:longitude and schema:latitude as used in some sample files example: https://opengeospatial.github.io/ELFIE/nrcan/gwmon/cr/prj_27.53527 As @abhritchie suggested in #107 , schema is indeed useful for indexing, we just noticed that aliases of longitude and latitude are not defined in the contexts.

[dblodgett-usgs]

Ahh! Yes. That makes sense. Will add. So my comment here is more appropriate to #134.

[lieberjosh]

The processing referred to is compatibility with RDF, which doesn’t have nested sorted lists. So any nested coordinate lists representing geometries have to be preserved as opaque literals wrt RDF and processed separately from any standard JSON-LD processing or they will be mangled. Geometric coordinate lists usually need special treatment anyway, which is why they are serialized in WKT for geosparql.

—Josh

On Feb 12, 2018, at 9:14 AM, David Blodgett notifications@github.com wrote:

Unfortunately, latitude and longitude are not defined by the geojson namespace. https://purl.org/geojson/vocab# https://purl.org/geojson/vocab# doesn't contain latitude or longitude. Doing some snooping at http://geojson.org/geojson-ld/ http://geojson.org/geojson-ld/ -- I see this:

Nested GeoJSON coordinate arrays are incompatible with the processing model of JSON-LD 1.0. There are no current best practices for addressing this issue. Applications that process GeoJSON as JSON-LD using the GeoJSON-LD 1.0 context must take extra steps not defined here to ensure that geometric coordinates are processed appropriately.

This leaves us with two options -- 1) break the rules and point out that this issue needs to be solved or 2) scale back our ambition to encode geojson geometries directly in our json-ld documents by linking to them directly instead.

I had already been considering doing #2 https://github.com/opengeospatial/ELFIE/pull/2. @abhritchie https://github.com/abhritchie @jkreft-usgs https://github.com/jkreft-usgs -- you two have been the most active in this discussion, what say you?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/ELFIE/issues/135#issuecomment-364934234, or mute the thread https://github.com/notifications/unsubscribe-auth/AExWhmftbTBLxllLd0U7wneEDW02XWFWks5tUEddgaJpZM4SB8Wr.

[dblodgett-usgs]

Thanks for the clarification, @lieberjosh. We are now commenting on the wrong thread though. I'm fixing this issue then will close this and #134 in favor of starting a single focused issue to discuss how to deal with preview geometries.

Many many thanks to @afeliachi for spending time reviewing this work.

[afeliachi]

you are welcome