Consider navPlace property
Closed this issue · 20 comments
Instead of a GeoJSON-LD service, we might consider an equivalent property to navDate to capture the information. This seems like a logical extension, and would be practically a drop in replacement for the current service pattern, with the same caveats as navDate as to lack of semantics.
So enough to see a place name label, but not the kind of information which would allow for a map view navigation?
No, enough to render it on a map UI. To swap time and space for navDate to navPlace, something like:
A date GeoJSON-LD block that the client can use for navigation purposes when presenting the resource to the user in a time location-based user interface, such as a calendar or timeline map.
I think GeoJSON is too flexible for that to work--It's possible (and not unusual) to have the entire boundaries of every country as part of a GeoJSON file. I could see a point-style interface (lat/lng), but not something that flexible.
If clients can display arbitrary boundaries, I think we should allow the content to describe them. Limiting to just lat/long points seems like limiting navDate to just years.
It's not just a boundary—for instance, geoJSON could contain an array of Lat/Lng points for every major city in America, as well as a country boundary, plus the flight paths out of Heathrow as vector lines.
I'm not opposed to it, I just want to be sure we know what we're getting into.
True, and navDate is only a point rather than a range.
Thoughts @mejackreed and other Geo folk?
At NLW we had two use cases for some kind of NavPlace:
For the crowdsourcing project they are asking users to geo-locate photographs to a point on a map and with a navPlace it could be used to drive an interface similar to: https://www.peoplescollection.wales/locate/query/castle
The second use case was for Maps and we would have liked to share a bounding box to show where the map covered. This data could be used to drive something similar to http://www.oldmapsonline.org/ if used in combination with navDate.
Would navPlace have any semantics associated with it? Or just purely for navigation purpose? I could see how people might want to stuff additional things into this.
👍 to using GeoJSON but with the caveat that @workergnome brings up. You can essentially stuff anything in here and also, one might include complex geometry here. A classic example is the complex geometry of New Zealand https://whosonfirst.mapzen.com/data/856/333/45/85633345.geojson (120 MB).
Additional considerations to think about:
- there has been some work by nypl-spacetime to express photograph locations in GeoJSON including angle, bearing, and distance http://spacetime.nypl.org/Leaflet.GeotagPhoto/examples/camera.html I wonder would people want to include similar types of things?
- Klokan has done some work on georectifying iiif images. This would potentially apply a transformation to an image. So could a
navPlacecould be geodetically correct with transformation information? - often times things have multiple locations, would that be allowed?
Very much 👍 for at least the single point case
Would
navPlacehave any semantics associated with it?
Purely for navigation / display.
As much as I love my New Zealand 😀 , expecting a IIIF client to render 120 MB of geojson is not realistic. So is this a spec MUST on something simple, or a SHOULD? And what is the best version of "simple"? It could easily be point or box ... is there something between box and New Zealand coast line?
Perhaps:
MUST have a FeatureCollection object that MUST contain a Geometry object, which SHOULD contain a single Point object representative of the navPlace. MAY contain additional Geometry objects. MAY contain a BoundingBox member object representative of its Geometries, Features, or FeatureCollections.
This feels complicated.
Ed's proposal: Useful feature to add for v3. As the data will be embedded in the manifest, the 120Mb NZ issue is less of a concern. If content creators put in descriptions that are too complex to be implemented anywhere, then they'll reduce it down to something that can be implemented. No proposal for what the value should be, other than geo-json, and will work with geo folks (hi all above!) to find an appropriate set of examples.
Does it bother us at all that GeoJSON-LD is, for the most part, completely unsupported? Once it's inline, it's either no longer geoJSON, which means it can't be used, or it's no longer round-trappable through RDF, which means it's against our principles.
In Linked.Art, we've been talking about WKT as an alternative for this. See discussion here.
(See json-ld/json-ld.org#397 for a discussion of the issue with GeoJSON: Tl;dr:, [[-70.123,43.123],[-66.123,40.11]] isn't expressible in JSON-LD.
It seems to me like GeoJSON optimizes here for simplicity and client adoption. WKT optimizes for full semantic expression (am I saying this the correct way?). GeoJSON has seen widespread adoption because of its simplicity. I would be +1 to GeoJSON for that reason, but not in opposition of WKT.
i am 👍 on GeoJSON in general. I am 👎 on GeoJSON-LD, since it's not actually GeoJSON, and can't consistently be directly parsed by any existing implementations that I'm aware of. Given IIIF's desire to remain an LOD spec as well as a JSON one, I'm more willing to accept WKT because there are existing software libraries that will convert it to GeoJSON, as well as many that support it natively.
WKT seems like a good compromise, especially as it avoids the GeoJSON / GeoJSON-LD discussion. It's nice and compact, although not quite as developer-friendly as GeoJSON. Perhaps there should be a RECOMMENDED statement on how the geometry should be as minimal as possible while still enabling useful navigation.
Discussion on 11/22 call: Need use cases and implementation experience of building map based navigation UIs for Manifests. Backwards compatible so defer.
I spent some time discussing this idea with @glenrobson today. Here are some resulting thoughts and examples.
We are running into this in the Maps group because we are trying to make geographical assertion recipes for IIIF. We have run into a fork of ideas where we see potential routes to including GeoJSON(-LD) in presentation API 3 objects.
-
Without
navPlacea service was used inside the manifest. The working manifest that uses a service can be seen here.. This had some complications as the@contexthad to include a term for my GeoJSON service in the active context and we had to scope GeoJSON-LD context to the root context. This was important to handletype, since GeoJSON and IIIF services require atypeat the same level. There was some consideration given to implanting the GeoJSON as plain JSON, buttypestill requires special consideration. -
This gave way to wondering about what it might look like with the extension being proposed here in place of the service. Having tried to implement this through recipes, I found this to be the most sane solution. The working manifest that uses the
navPlaceextension can be found here. -
Along another prong of the fork, we realized that we could make GeoJSON as the body of Annotations. Instead of using a service block, an embedded annotation page was used. The working manifest that uses the AnnotationPage can be seen here.. This was much cleaner but still required one to scope in the GeoJSON-LD context.
Though I cannot cite specific institutional use cases beyond our own, I can assure you these are the base recipes for making any geographical assertion. It is evident that a decision on this point is required to have the foundational building blocks necessary to make geographical assertions under IIIF.
Maps TSG considering this as an extension.