Nerdy #GIS post but anybody know why would I ever want a GeometryCollection over a FeatureCollection in a GeoJSON file? Seems to break a number of tools like QGIS and tippecanoe
=> More informations about this toot | More toots from jeremiak@journa.host
@jeremiak Despite both having *Collection in their names they are not equivalent in terms of hierarchy! GeometryCollection is a Geometry object just like Point, Polygon, etc.
So a Feature object's geometry member could be a GeometryCollection, and that Feature object could appear in the features array of FeatureCollection.
But what really makes them awkward is how unlike the other Geometry objects it doesn't support coordinates as a member, it uses geometries. 🫠
=> More informations about this toot | More toots from ryan@social.lol
So I'd guess tooling weirdness is caused by a combination of two factors — people are using them wrong and treating them like an alternative to FeatureCollection, and because they are the only Geometry that doesn't support coordinates it's not always accounted for.
FWIW the spec does basically say "maybe don't use this" so I think you have the right read on it! https://datatracker.ietf.org/doc/html/rfc7946#appendix-B.2
Here's the spec section on GeometryCollection itself too: https://datatracker.ietf.org/doc/html/rfc7946#section-3.1.8
=> More informations about this toot | More toots from ryan@social.lol
@ryan Thanks Ryan! That does help and explain things a bit. In this case the GeoJSON file is the output file of using mapshaper to convert and reproject a Shapefile but I just changed it to a feature collection instead and that seems to have done the trick.
Man, one of the crazy things about geo programming is that there's very rarely a midpoint - it's either wrong and therefore completely broken (aka doesn't show up on a map) or it's correct
=> More informations about this toot | More toots from jeremiak@journa.host This content has been proxied by September (ba2dc).Proxy Information
text/gemini