clarify use of GeoJSON geometry and properties.extent.spatial

[tomkralidis]

As discussed at the 2022-05-16 SWG, our current record model specifies the following properties for defining spatial.

• geometry (native from GeoJSON proper): can be any GeoJSON geometry, or null
• properties.extent.spatial: bbox

We should clarify the above in the cases where (in the least) the values are duplicate, yet required twice.

cc @pvretano @cportele

[pvretano]

I'm thinking of two approaches for handling this issues ...

First, we can add words to the specification that say:

• the geometry member stores the geometry of the resource; this can be its actual geometry or some other representation of the space the resource occupies for the purposes of discovery
• the extent member stores the extent of the geometry of the resource; these could infact be the same thing if a server chooses to use the bounding box as the representative geometry of the resource

The second approach uses JSON-FG rather than GeoJSON. Using JSON-FG gives us:

• A place to store the spatial extent (i.e. the geometry member)
• A place to store the temporal extent (i.e. the time member)
• Support for CRS other than CRS84 (should a server want to implement the CRS extension of Featrures)
• Support from 3-D geometries (that might be an emergin thing, I don't know)

This would mean that in the specification we:

• remove extents from the record
• add a requirement that say that JSON-FG must be generated using maximum compatability (to GeoJSON) mode so that GeoJSON clients can still read the record without any trouble
• Add words that say if additional extents are required then communities of interest can add them to the properties section

Thoughts?

[pvretano]

2022-05-30: With regard to JSON-FG, after a long discussion, the SWG decided to implement the following in the specification

• Remove the "extent" member from properties.
• Add a "time" member to properties with the same structure as the JSON-FG time.
• This will be added to the "GeoJSON" conformance class.
• There will be no JSON-FG conformance class for now but only a note indicating that the specification will add one at some future time when the JSON-FG specification is available.
• The "time" member in the GeoJSON conformance class will remain there, in that class, for all time!
• When the JSON-FG conformance class is added, it will using JSON-FG as designed and there will be a "time" member at the top level ... but this is a different thing than the "time" member in the GeoJSON conformance class.

[tomkralidis]

@pvretano: some comments, questions:

• I see a JSON-FG conformance class the latest updates to the repo. Is JSON-FG now available?

• for completeness, can we change time to datetime?

  • queries:
    • datetime is a parameter from OGC API Common
    • many OGC APIs already support the datetime parameter, per RFC3339
  • JSON Schema delineates date, time, date-time, for example
    • so do many programming languages
  • time COULD result in confusion (emitting JUST the time with no date?)

• can we add the following to the (currently named) time object:

• trs, or is one assumed/implied (that we should qualify/document)

• resolution, per add extent.temporal.resolution property (#147) #149

• I'm not sure if these are best routed / cc'd to JSON-FG as well

• we still have core/openapi/schemas/common/extent.yaml; guessing we should remove?

[pvretano]

@tomkralidis

1. JSON-FG - was added as a placeholder until after the code sprint but I don't think we will adding it to the specification in this version. Instead we will adopt some of the "features" of JSON-FG (i.e. the time object).
2. Nope. We took time from JSON-FG as a stepping stone to eventually fully supporting JSON-FG. If we want to change the name we need to convince the JSON-FG guys to change the name of their key to datatime first.
3. From JSON-FG, the trs is fixed to the Gregorial calendar so a trs member is not required.
4. Yes, any changes to the time object should be routed to the JSON-FG group. In records we are simply trying to align, in this respect, with what JSON-FG is doing so that at some point in the future we can add a JSON-FG conformance class and the transition will be as effortless as possible.
5. Yes, extent.yaml should be removed. I'll take care of that with my next PUSH to the repo.

[tomkralidis]

Nope. We took time from JSON-FG as a stepping stone to eventually fully supporting JSON-FG. If we want to change the name we need to convince the JSON-FG guys to change the name of their key to datatime first.

Good point. I've opened a related issue at opengeospatial/ogc-feat-geo-json#56

[cnreediii]

Just a FYI: datetime in CDB is stated as a requirement:

Searchable date and time. This may be a time instance or time period. The specification of date and time in any CDB metadata SHALL be specified in UTC and SHALL be formatted according to RFC 3339, section 5.6. RFC 3339 is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.

Look familiar. However, the CDB SWG has also discussed how to deal with time intervals. The requirement for time intervals will be different as time sampling scales such as Unix time need to be accommodated.

[pvretano]

28-NOV-2022: It was agreed at the code sprint that JSON-FG is not, at this time, relevant to records. @pvretano will review the issue to make sure that all parts have been addressed and close.

[tomkralidis]

@pvretano it may be valuable to align the OARec record time to JSON-FG just the same. OARec currently defines time as either a string or an array (begin, end), whereas JSON-FG defines an object, which contains either a date, timestamp, or interval. The JSON-FG approach provides an easier time for (backend metadata repository) things like document indexers (i.e. it is easier to index time.date [string], and time.timestamp [string], and time.interval [array] than time, which can have multiple non-null types).

Thoughts?

[mariadb-pvretano]

@tomkralidis agreed. Our time field should align with JSON-FG. I'll make the necessary changes.