Access to top-level members in a GeoJSON feature

[cportele]

This issue was discussed in the meeting on 2023-05-15.

In OGC API Records there is a discussion whether time etc. should be a top-level member in the GeoJSON feature object or whether it should be inside the properties container object (see the discussion starting with opengeospatial/ogcapi-records#168 (comment)).

While the reasoning for time, featureType, coordRefSys, etc. as top-level members like id or geometry, separate from the domain/application-specific values in properties still seems justified, this can make it hard(er) to use the data in clients. OpenLayers was mentioned as one example, where access is to the id, the geometry and the properties object, but "custom" top-level members cannot be accessed. Other tools likely will be using a similar approach.

Options include:

• Stick to the current approach and accept that some tools will need an update to make use of JSON-FG extensions.
• Move GeoJSON extensions into properties to simplify access in existing tools supporting GeoJSON, likely using special names as $time, $featureType or $crs to highlight their special role and reduce naming conflicts.
• Do both.

After some back and forth between those options, there was a preference for keeping the current approach, but with a new recommendation to also include the information in the properties object in cases where it is expected that the data may also be used in clients that do not support access to new members outside of the properties object.

We will keep this issue open for some time to see, if there is any additional feedback or experience. We should also monitor the discussion in OGC API Records.

In the discussion, we also noted that other GeoJSON extensions have also made use of top-level members (STAC, for example, uses conformsTo (see also #70), assets, links or stac_version as top-level members.

[cportele]

Meeting 2023-08-21: We still think that we still have a preference for keeping the current approach, but with a new recommendation to also include the information in the properties object in cases where it is expected that the data may also be used in clients that do not support access to new members outside of the properties object. @cportele will create a pull request.

[cportele]

While working on the text in #95 I also had another thought: We already have the GeoJSON compatibility "mode" for the "geometry" member. Should we tie the recommendation to that mode only, i.e., if the "compatibility" media type parameter is set?

[cportele]

Meeting 2023-09-18: The PR #95 covers what we have decided previously, but we should discuss the previous comment on the use of the compatibility mode in the next meeting where we have more participation (eg Singapore).

[cportele]

We decided to merge the pull request, but keep the issue open to discuss whether the recommendation to include the top-level members also in the "properties" member should apply only in the "GeoJSON compatibility mode" (i.e., if the "compatibility" media type parameter is set).

[cportele]

Closing this issue, the discussion in now in the profile "JSON-FG with improved support for GeoJSON readers".