Hi, I came across this project via https://twitter.com/terradue/status/643799926766481408 and have looked at your JSON examples. I appreciate the all the standard Atom-inspired metadata (authors, contributors, updated, etc) but I believe that putting these in a feature's property
object is not the best practice.
The items are completely opaque to Leaflet, of course.
![owscontext sea_ice_extent_01 json at master opengeospatial owscontext](https://cloud.githubusercontent.com/assets/33697/9882090/438394c2-5b90-11e5-9249-227876669c39.png)
And to change this situation, to add the semantics of authors and links and offerings to Leaflet (or other map libraries), will require either
- Fixing these terms within the libraries, meaning that applications can't make other kinds of references to "authors" in their feature properties without name conflicts, or
- Leaflet will need to become namespace aware, through JSON-LD or something.
Mapbox's simplestyle spec (supported by GitHub) puts us in a bad position with respect to 1 above. It introduces many possible name conflicts ("width", "color", all these names are squatted on by styling now). The owscontext proposal would add to the existing conflicts. Making an awkward situation worse. On 2 above, making a JSON-LD version of Leaflet is a bit of a lift.
I see two alternative places in GeoJSON for the context metadata, two places that don't depend on 2 (above) and don't make the situation of 1 worse.
a. Put owscontext metadata in Feature.owscontext
instead of Feature.properties
. In JSON, every object is a namespace and so this is the JSON native style of namespacing data elements.
b. Put owscontext metadata directly under Feature
alongside id
and geometry
and properties
.
Myself, I'm inclined toward b. updated
, title
, etc should be siblings of id
in GeoJSON just like they are in Atom. And these properties are globally useful, not just for owscontext. I'd like to see them used by every GeoJSON publisher.
Now, there is the issue of GDAL's GeoJSON driver. It throws away all Feature
data other than geometry
and properties
– a terrible design decision – and will need to be updated if we're every going to get away from just dumping everything into Feature.properties
.