GeoJSON doesn't encode the fact that the boundary points are common between adjacent polygons. When you simplify those polygons, each one is handled separately, and you end up with "slivers" where the boundaries are misaligned:
https://www.bing.com/images/search?q=map+slivers+betwen+poly...
TopoJSON solves this by encoding each such boundary only once. So when you simplify the polygons, they are all done together, and the same simplification applies to adjacent polygons. No more slivers!
The dangerous part is that some tools fully assume this and will completely screw with calculations if you’re assuming a flatland CRS. So you’ve got to be careful in checking and setting those parameters.
One nice thing is that the structure of GeoJSON works incredibly well in typescript. It has discriminated unions built in so you can walk entire geodatasets in a pretty comfortable way.
But thankfully there is also the SQLite backed GeoPackage, which is not only more flexible but also much smaller. It takes some extra steps to get testing teams working due to it’s binary nature, but other than that it is the best format in geospatial data analysis.
Long live SQLite!
[0] https://github.com/OpenDataDE/State-zip-code-GeoJSON/blob/ma... although you can generate newer versions from the last census.
GeoPackages also allow to set a proper CRS, which is not as easy in GeoJSON IIRC.
Getting your CRSes wrong is fun...
If you have a non-insignificant amount of data points to track this is going to eat just a ton of memory while also being pretty slow to encode/decode.
Imagine, for example, if we encoded this as a binary. First 2 bytes for the feature type, second 2 bytes for the geometry type, 3 bytes for a fixed point x, 3 bytes for a fixed point y, and you could optionally provide the properties as a json blob in a trailing string. That's 10 bytes for all the coordinate stuff. Less bytes than what currently stores the `"type": "Feature"` string.
QuPath[1], a tool for digital pathology whole slide image analysis, can export annotations in GeoJSON format (and import too I suppose).[2] This makes it really very easy to make annotations transportable between tooling.
[2] https://github.com/qupath/qupath-docs/blob/main/docs/advance...
A few weeks ago I (vibe)coded mxmap.be and if not for the ubiquity of geojson, it would have taken me significantly more effort.
geojson.io is a great editor/viewer by Mapbox. Also https://kepler.gl/demo is great for additional filtering, visualizations like heatmaps, arcs etc.
A extension to GeoJSON that works with JSONL-like semantics would be great for huge files, but this could also be solved by tiling.
You can save a lot of RAM by using an array of interleaved coordinates. For an additional bonus, you can also compress rings by storing the ring offsets inside a larger array.
All that said, GeoJSON was a great change of pace, I enjoyed using it. While I'm no professional and have no idea what the professional needs are, it was very good for my hobbyist needs.