Always include 'geometry' when 'place' is not null?

[cportele]

GeoJSON states:

The value of the geometry member SHALL be either a Geometry object as defined above or, in the case that the Feature is unlocated, a JSON null value.

Currently you can have a place member that is non-null, but the geometry member can be null. However, the feature is obviously "located". Shouldn't we always require a non-null geometry member, if the place member is non-null (i.e. at least some representative point) to make clear that the feature has a location?

Raised during the 2022-09 Code Sprint.

[m-mohr]

The part of the GeoJSON spec that (I think) requires this:

The value of the geometry member SHALL be either a Geometry object as defined above or, in the case that the Feature is unlocated, a JSON null value.

Highlighted text by me...

[IvanSanchez]

An interesting case is non-geographical geometries. I'm specifically thinking on 2D cartesian geometries, i.e. those in the OGC:engineering-2d CRS.

For those, it's just not possible to provide a fallback geometry that complies with the GeoJSON spec, since it's not possible to translate their coordinates to WGS84 (et al), and their raw coordinates fall outside the [-180,180],[-90,90] range (and cannot be used directly in GeoJSON).

Maybe they're not unlocated, but I'll say that they're unlocatable in WGS84 (in my understanding of the specs).

Another edge case is lunar/martian/etc CRSs (IAU:*). I'd rather leave those out as well rather than mapping to earth's WGS84.

Me personally, I'm fine with having null geometrys in JSON-FG. It won't really break backwards compatibility AFICS.

[cportele]

Meeting 2022-10-31: If there is a JSON-FG feature with a "place" member, but "geometry" is null, this does not break GeoJSON and it basically is an unlocated feature for GeoJSON clients. And it seems unjustified to add the geometry object to a "geometry" member, if the generating software knows that the targeted client won't be using this information. So we will stick with the current approach. @cportele will write a PR to add a brief discussion to the document, this will close this issue.