Implement `geo_traits` for `geojson` types.

[frewsxcv]

• [x] I agree to follow the project's code of conduct.
• [ ] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

---

[kylebarron]

Still need to implement for Feature (and FeatureCollection?), but that should be easy.

I wouldn't necessarily expect the traits to be implemented on Feature and FeatureCollection. I think it's fine if they're only implemented on the geometry structs.

[kylebarron]

I don't particularly like the overloading of unknown(0) here, because we're using the same enum variant to say both "we have a known number of dimensions but we don't know their semantic meaning" and "we don't know how many dimensions exist". I think it would be clearer to add a new enum variant to make both meanings clearer.

[frewsxcv]

Sounds good to me. Conceptually, would that be much different than updating it to return Option<Dim>? I'm fine with any approach here. Just curious how you're thinking about it.

[kylebarron]

Sounds good to me. Conceptually, would that be much different than updating it to return Option<Dim>? I'm fine with any approach here. Just curious how you're thinking about it.

That would be the same as Option<Dim>. I wish consumers didn't have to check if the dimension is None, but perhaps that's the only way to solve some producers like GeoJSON

[frewsxcv]

I wish we could bundle the dimension and the non-empty geometry together. Something like Empty | (Dimension, Geometry) rather than (None, Empty) | (Some(Dimension), Geometry).

[kylebarron]

I wish we could bundle the dimension and the non-empty geometry together.

I believe in Simple Features they're considered separate. E.g. in WKT you can have any of:

POINT EMPTY
POINT Z EMPTY
POINT M EMPTY
POINT ZM EMPTY

So you can't merge them into a single concept.

[frewsxcv]

Ah darn 😞 . You're totally right