STAC <-> JSON-FG mapping

[m-mohr]

For informational purposes only: As STAC Items are GeoJSON it is easy to also add the JSON-FG building blocks in addition. Nevertheless, STAC also partially covers parts of JSON-FG in a different way. I'm trying to figure out what you'd add to JSON-FG to make it STAC-compliant.

• time: dates only not supported by STAC, only timestamps with date and time
  • date -> n/a
  • timestamp -> properties.datetime
  • interval -> properties.start_datetime / properties.end_datetime (not available for date only) - the ".." syntax for open-bounds may need to be translated to null.
• place -> n/a, partially covered by the projection extension (proj:geometry), but no additional types allowed
• coordRefSys -> projection extension (proj:epsg, proj:wkt2, proj:projjson), but different encodings and no direct support for compound CRS
• featureType -> n/a, but in STAC you'd usually have this in properties so that you can better search on it.

[cportele]

A few comments on the differences:

• JSON-FG adds members outside of the "properties" member to not interfere with the content of "properties", which is controlled by the generator of the data and may contain anything as needed for the intended use. This is a key design principle to also make information available to readers independent of how a community might represent the information in the "properties" member.
• This is different in STAC which basically specifies an application schema, i.e., properties to be added in the "properties" container. If a STAC instance would be encoded as JSON-FG, the relevant information would have to be duplicated in the "time", "place", "coordRefSys", "featureType" members of JSON-FG.
• JSON-FG uses ".." for unbounded time interval ends to align with CQL2 JSON, which changed from null to ".." to align with CQL2 Text encoding. However, we could in general also switch back to null in both JSON-FG and CQL2 JSON, if we think that would be less confusing (CQL2 JSON is also used in STAC API).
• "coordRefSys" in JSON-FG currently does not support full CRS definitions in WKT2 or PROJJSON, only CRS by identifier(s) plus coordinate epoch.

[cportele]

OGC Code Sprint 2022-09-15:

• There was agreement that the different approaches where to put properties are the result of the scope of the JSON-FG and STAC specifications. As stated above, if a STAC instance would (in the future) be encoded as JSON-FG, the relevant information would be duplicated in the "time", "place", "coordRefSys", "featureType" members of JSON-FG.
• It would be good to revisit the ".." (based on ISO 8601) vs null representation for unbounded interval ends.
  • OGC API Features uses null in JSON interval arrays in the temporal extents of a Collection resource.
  • OGC API Features .. in the datetime query parameter since the parameter uses the ISO 8601 interval text encoding.
  • CQL2 Text and CQL2 JSON currently use "..". Earlier this was null in CQL2 JSON, but was changed to align with the CQL2 Text.
  • JSON-FG also used null, but changed to ".." to align with CQL2 JSON.

This should be re-discussed in the Features API SWG before finalizing CQL2. Options include:

• Always use null in JSON. A NULL keyword could also be added in CQL2 Text. The datetime query parameter uses the ISO 8601 text interval encoding with / as the separator and therefore also ...
• Always use null in JSON responses (Collection resource, JSON-FG), but continue to use ".." in filters (i.e. CQL2).
• Leave as is.

[m-mohr]

I like all options except "leave as is" ;-)