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.
I vibe coded something similar (different data source) with codex that went something like SQLite->GeoJSON->Leaflet and it was a dream - almost no corrections necessary. It even went off and found a really nice colour scheme for me.
[0] https://github.com/OpenDataDE/State-zip-code-GeoJSON/blob/ma... although you can generate newer versions from the last census.
For missing ones you have to fall back to distance based estimates and in my business that means you’re quote may be off and you’re exposed
That said, this is a textbook example of what I have always found so infuriating, personally, about working on commercial software, and one of the many reasons I ultimately moved into a non-software-writing role. The (very sensible and practical) shortcuts and tradeoffs that are commonly made due to time and cost constraints. The attitude of "well the vast majority of our use cases work, so we're done." I've always thought edge cases must be addressed. Something in my brain hurts when I knowingly release something where only 99% of cases work.
I can imagine this is probably the same thing some artists feel when they are commissioned to produce (in their view rushed, flawed, or incomplete) artwork for business purposes.
I only write software at home, as a hobby now, and this gives me the outlet to follow my heart around edge cases!
also i hear your point on swe roles and don't disagree
[0] https://docs.postgrest.org/en/v14/how-tos/working-with-postg...
[1]: https://github.com/PostgREST/postgrest/blob/f1d0e8ea2266077d...
[2]: PostGIS has https://postgis.net/docs/AsTopoJSON.html but it doesn't take a record.
I've found it very useful for storing geospatial data over time.
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.
Sounds like Amazon
I thought the spec allowed you to specify the CRS, but I just checked the RFC and they removed that from the 2016 specification and WGS84 is specified. It does allow for alternative CRS with prior arrangement, but like you said that does require a lot of care.
The spec doesn't say what type the value of a property can be, though. Examples in the RFC show strings, floats, and a nested object. So you could probably put a list in there as well if you want to store multiple values under the same key, provided that your decoder knows what to do with such values. (GeoJSON is often converted to and from WKB/WKT, and unorthodox values may be lost in the conversion.)
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.
GeoPackages also allow to set a proper CRS, which is not as easy in GeoJSON IIRC.
Getting your CRSes wrong is fun...
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!
so you need a stream-based parser, which nobody does an effort to write/use for json. especially since geojson is a web format, and people just default to json.parse, which is blocking. and even then, even if you did use the custom one, it likely won't be a geojson-tailored one, so because key-order isn't guaranteed, any parser for geo-json will need to do some acrobatics to finding the reference-system, dealing with arbitrarily nested geometries etc..
it's a good format for what it is, but it's not a great geo-format. a geo format needs to be easily scannable and, even better, have a geometry index to be able to seek quickly.
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.
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...
> The coordinate reference system for all GeoJSON coordinates is a geographic coordinate reference system, using the World Geodetic System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units of decimal degrees.
So that seems to be a misuse of the format. Using a geojson library for this may get you into trouble with ranges or antimeridian cutting.
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!
From what I can tell, the top criticism of GeoJSON is the under-enforced winding order specification, and crossing the antemeridian.
I don't think I would trust a zebra or a giraffe for this task either.
Is there much work developing or using TopoJSON these days? I haven't seen much about it in a few years.
I'm just saying that for the specific task I mentioned GeoJSON or any format such as shapefiles that store polygons individually naturally leads to the "sliver" problem.
A nice processing pipeline is:
1. Convert GeoJSON to TopoJSON.
2. Run the simplification on the TopoJSON.
3. Convert the resulting TopoJSON back to GeoJSON.
The TopoJSON GitHub has tools for each of these steps.
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.
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.