nullability of "geometry"

[jfirebaugh]

According to the GeoJSON spec, a Feature can have a null "geometry".

To support a nullable "geometry", we need to make a change in geometry.hpp: Feature::geometry needs to be optional< geometry_type>.

[jfirebaugh]

Edited to remove references to non-nullable "properties" -- "properties" can be null in GeoJSON.

[jfirebaugh]

@sgillies -- What was the thinking behind making Feature "geometry" nullable in GeoJSON? Is this something that you think is important to faithfully represent in GeoJSON bindings for static languages? (I note that rust-geojson does not seem to support null geometry.)

[mourner]

Feature::geometry needs to be optional< geometry_type>.

Can it have a nullptr_t among variant types instead? It seems to me that this way we the API would be more consistent.

[jfirebaugh]

That's not quite the same thing, and allows some things that GeoJSON does not. For example, a GeometryCollection is not allowed to have nulls in the "geometries" array.

[jfirebaugh]

Prior discussion about empty geometries: mapbox/geometry.hpp@a86baac

[mourner]

@jfirebaugh does this mean we will have to use feature.geometry.value or something similar instead of just feature.geometry?

[jfirebaugh]

*feature.geometry or feature.geometry->..., yeah. Preceded by a null check. This is why I don't want to introduce nullability for geometry more generally than is absolutely necessary.

[mourner]

Eh, I think I'd still prefer supporting null values in geometries than making geometry access so inconvenient. :(

[sgillies]

@jfirebaugh Features with an undefined geometry are interesting to a small number of users. I don't know how many exactly, but I used to be in that camp – the application I was developing before I came to Mapbox had fictional and unlocated or roughly located places. As to why the spec says geometry MUST be null instead of being omitted, this is because the authors were split on how to express the types of GeoJSON objects. I argued that duck typing (e.g., presence or absence of "geometry" and "properties" members) would suffice, others wanted a "type" member. We ended up with both.

The "geometries" member of a geometry collection can contain nulls (https://tools.ietf.org/html/draft-ietf-geojson-02#section-3.1.8):

A GeoJSON object with type "GeometryCollection" is a geometry object.
A geometry collection MUST have a member with the name "geometries".
The value of "geometries" is an array. Each element of this array is
a GeoJSON geometry object. It is possible for this array to be
empty.

Or wait... maybe it doesn't exactly say that. My interpretation has always been that the following (from https://tools.ietf.org/html/draft-ietf-geojson-02#section-3.2) applied to elements of "geometries"

A feature object MUST have a member with the name "geometry". The
value of the geometry member SHALL be either a geometry object as
defined above or, in the the case that the feature is unlocated, a
JSON null value.

but that's not actually clear in the spec.

[jfirebaugh]

Thanks for the perspective @sgillies.

The "geometries" member of a geometry collection can contain nulls

Did you mean "can't contain nulls"? I don't see anything in the language you quoted that would allow nulls.

[sgillies]

@jfirebaugh I edited as you were typing a response. I can't think of any harm in an implementation that allows a geometry collection's "geometries" member to contain nulls, but I do think that writing out a JSON array containing unnecessary nulls could cause harm: the meaning of nulls there is not specified.