General feedback and concerns about JSON-FG

[bjornharrtell]

Hi,

I have some general feedback and concerns about JSON-FG, which can be perhaps be broken out into several issues but I will attempt to summarise what I’ve found in my initial review of the current proposal.

I would like to start with the disclaimer that I’ve not involved myself prior to this feedback and some of my concerns might be misunderstandings or due to rationale from earlier discussions that I am not aware of.

In general I feel the core standard of JSON-FG is proposed to contain too many what seems like mandatory extensions. Specifically I feel that these extensions should be non-core extensions:

• The ability to use non-Euclidean metrics, in particular ellipsoidal metrics
• Support for solids and prisms as geometry types
• The ability to encode temporal characteristics of a feature

As for "The ability to declare the type and the schema of a feature" I'm undecided as of yet but it might well be a good idea to include in the core standard.

As for "The ability to use Coordinate Reference Systems (CRSs) other than WGS 84 (OGC:CRS84)" I feel it is the main important feature of JSON-FG and should be in core. However, I fail to see the benefit of implementing this in a different and non-compatible way vs GeoJSON 1.0. I fail to see why it would be a good idea to introduce redundant and/or optional "place" property instead of just adhering to GeoJSON 1.0 and current GeoJSON (which does permit other CRS in "geometry" on agreement). Introducing "place" means JSON-FG will contain redundant data and/or be non compatible with existing GeoJSON (when "geometry" is omitted due to the and/or wording).

In my opinion compatibility with GeoJSON and GeoJSON 1.0 is very important to keep existing data usable and adoption of JSON-FG and extensions to it, or JSON-FG might be better off as a standalone standard.

[rouault]

• Support for solids and prisms as geometry types

I feel like there is an inconsistency in providing 3D geometry types in JSON-FG, while not providing curve/arc ones (cf https://github.com/opengeospatial/ogc-feat-geo-json/issues/35 / https://github.com/opengeospatial/ogc-feat-geo-json/issues/77). Curve geometries are needed to be able to migrate from WFS (over GML) scenarios to OGC API features (over JSON-FG) for some data models

[cportele]

@bjornharrtell - Thank you very much for your feedback, your review is very much appreciated.

The working group discussed your comments in the meeting on 2024-04-29. I include some initial responses in this comment (apologies that it took so long to capture the notes):

In general I feel the core standard of JSON-FG is proposed to contain too many what seems like mandatory extensions.

Only the "Core" requirements class is mandatory. Support for "3D" (polyhedron or prism geometries) or "Feature Types and Schemas" is optional. Use of these options are declared in the "conformsTo" member. If they are not relevant for the specific use case, these extension will not be used.

Specifically I feel that these extensions should be non-core extensions:

• The ability to use non-Euclidean metrics, in particular ellipsoidal metrics

You make a good point. In fact, this is currently just a permission, but there are no requirements and it is unclear to consuming software which metrics they should apply when, for example, computing the intersection between two line strings.

Support for non-Euclidean metrics should be optional and specified in an additional requirements class that signals to processors that ellipsoidal metrics should be used when processing the geometries (e.g., of flight paths).

Processors can, of course, ignore this information and apply Euclidean metrics.

Without this optional requirements class in "conformsTo", Euclidean metrics would always apply like in GeoJSON.

• Support for solids and prisms as geometry types

See above, this is optional, i.e., a separate requirements class. 3D data is now quite frequently used and there should be an option to support it in JSON-FG.

• The ability to encode temporal characteristics of a feature

In general, temporal information about a feature is very often an important aspect in geospatial data in addition to the spatial information, so it is seems valuable to support it in JSON-FG. That said, it is an option and if a generator does not want to include temporal information, it can just simply write "time": null.

One option to make this even simpler could be to not make "place" and "time" required, so no null values has to be written, if there is no value to include.

As for "The ability to use Coordinate Reference Systems (CRSs) other than WGS 84 (OGC:CRS84)" I feel it is the main important feature of JSON-FG and should be in core. However, I fail to see the benefit of implementing this in a different and non-compatible way vs GeoJSON 1.0. I fail to see why it would be a good idea to introduce redundant and/or optional "place" property instead of just adhering to GeoJSON 1.0 and current GeoJSON (which does permit other CRS in "geometry" on agreement). Introducing "place" means JSON-FG will contain redundant data and/or be non compatible with existing GeoJSON (when "geometry" is omitted due to the and/or wording).

The reason for introducing "place" and "time" is that the "prior arrangement" permission that is included in GeoJSON does not apply here. This requires that all parties that will ever process the document know which CRS is used. This works in the case when a client requests from an API that data is a specific CRS, but for a JSON-FG document that just sits in a git repository, an S3 bucket, etc. this is in general not the case. A GeoJSON client that processes such a document will not know that the geometries are not in CRS84.

In addition, you cannot encode a non-GeoJSON geometry type in the "geometry" member. Additional geometry types like a polyhedron would always have to be encoded in an additional member.

Regarding compatibility with GeoJSON 1.0 from 2008, this is not possible in general. The "crs" member from GeoJSON 1.0 is not able to support a compound CRS (3D data in a projected CRS often uses a compound CRS with a 2D projected CRS and a 1D vertical CRS) or the coordinate epoch of a dynamic CRS. This is the reason why we introduced the new "coordRefSys" member that does not conflict with an existing GeoJSON 1.0 data that still may be out there (even if the obsolete GeoJSON version is no longer easy to find).

What might make sense could be to add a paragraph/recommendation how to include the "crs" member from GeoJSON 1.0, if it is likely that software might process the document that still supports GeoJSON 1.0.

Does this make sense?

[cportele]

@rouault - We discussed the support for arc/circle in the meeting on 2024-05-27 and agreed to work on a pull request to add support for them.

[bjornharrtell]

Thanks @cportele for the detailed response. In general it does make sense and provides answers for most of my worries or misunderstandings.

I did not understand the concept of requirement classes but it makes alot more sense now that I've read https://docs.ogc.org/DRAFTS/21-045.html#_conformance in more detail.

I can now understand the need to provide an entirely new way to represent geometry because otherwise would potentially clash with both new geojson and 1.0 and cannot support the additional geometry types.

I think it's worth considering your suggestion to "to include the "crs" member from GeoJSON 1.0". There is perhaps some drawbacks and risk of confusement... but I still feel it would be nice to accept and support that it is a valid way to represent simple projected data that do not need compound CRS etc.

[cportele]

Thanks for the quick reply, @bjornharrtell. I will work on a pull request over the next weeks to include the changes and also see, if we can improve the language to make things clearer. I will let you know, when the PR is available.