GeoJSON discussion Netherlands

[PalmJanssen]

This is a link to the GML.next GeoJSON discussion we opened this year:

https://geoforum.nl/t/gml-next-hoe-zet-je-json-geojson-in-als-lichter-alternatief-voor-online-toepassingen/1681

[pvgenuchten]

Short summary on the discussion:

• Use geojson as a file format or as a vocabulary (embedded in other json content)
• Use features of multiple featuretypes in 1 geojson
• Use features having different geometrytype (point/line/polygon) in 1 geojson
• Exposing features in alternative projection (base standard only allows epsg:4326)
• Use nesting of properties

Typical use case of geojson is: having 1 featuretype, having 1 geometrytype, having epsg:4326, having no nesting. Any deviation of this will break implementations somewhere.

GeoJSON is currently incompatible with json-ld

[thorsten-reitz]

Hi Paul(s), thanks for the summary. Adding rules on requiring just one feature type per GeoJSON file and having a homogeneous Geometry type would be possible.

At least for the two profiles that are currently in the spec, there are no nested properties, though there may be lists of primitive values (Strings, Numbers).

The current spec effectively treats EPSG:4258 and EPSG:4326 as equivalent to ensure compliance to the INSPIRE IR. Data sets for which this equivalence would be problematic may not use GeoJSON as an alternative encoding, only as an additional encoding.

[pvgenuchten]

Adding rules on requiring just one feature type per GeoJSON file and having a homogeneous Geometry type would be possible.

If applying strict geojson, also consider how to guide data providers on how to implement a transformation. For example if a GML has multiple featuretypes and/or geometrytypes, consider to advice to split the file in multiple files. Add a link to each of the files in Metadata or Atom.

A wfs response to a user requesting a simplified format will be more challenging. Maybe provide a zip-file having individual files for featuretypes and geometrytypes?