GeoJSON (opens in new tab)

One task where GeoJSON falls down is simplification of a group of polygons with common boundaries, e.g. the 48 conterminous US states. If you start with a highly detailed set of polygons, you need to simplify them for practical display in an online map.

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!

https://github.com/topojson/topojson

https://github.com/topojson/topojson-simplify

I’ve applied GeoJSON (among many other GIS tech) for mapping and monitoring tens of thousands of warehouse robots. It works great as long as you squint just a bit, ignoring that it generally calls for long,lat and is designed with the assumption of a world CRS.

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.

I’ve had nothing but problems using GeoJson. The specification has limitations everywhere and doesn’t even support z + m values at the same time.

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!

Made by Sean Gillies and a few others. Back when mapbox was doing all sorts of great open source stuff. Legends

https://github.com/sgillies

GeoJSON is super useful. At Getcho (delivery, logistics) we use zip code GeoJSON encodings to draw polygons on zone maps and quickly generate rates. This has been a persistently annoying thing to do until we discovered this format. If you're curious, someone made a repo with all the 2010 census zips a while back [0].

[0] https://github.com/OpenDataDE/State-zip-code-GeoJSON/blob/ma... although you can generate newer versions from the last census.

We used this extensively when I worked in this space (2010 - 2014). My favorite addition was using https://github.com/topojson/topojson to add arcs. That cut down on quite a bit of points to represent curves.

Have been using GeoJSON, very handy and human-readable, but we recently switched to GeoPackage files, as it allows for different layers, each with a different schema for additional data.

GeoPackages also allow to set a proper CRS, which is not as easy in GeoJSON IIRC.

Getting your CRSes wrong is fun...

Also https://postgis.net/

Interesting but, IMO, probably one of the worst uses of JSON. The data you would want to consume is already not "human readable" so it instead introduces a lot of bloat for really no benefit.

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.

Somewhat related: Falsehoods Programmers Believe About Map Coordinates: https://news.ycombinator.com/item?id=24659039

GeoJSON is not just for geographical features! Shapes of any kind work just as well.

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.

[1] https://qupath.github.io/

[2] https://github.com/qupath/qupath-docs/blob/main/docs/advance...

There's a map facility not linked here that allows you to build GeoJSON graphically:

https://geojson.io/#map=12.42/51.50593/-0.13003

Dunno whose website this is, but the format itself is great, and it allows for a relatively compact and relatively human-readable presentation.

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 love GeoJSON :) You can bring any Geo/GIS from 0 to visualization by just parsing it into GeoJSON.

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.

Have been using geojson for a while and was frustrated at lack of simple web tools play with it in browser. So I built https://geojson.page

This is nice. I haven't worked with GIS data for ages but I really like the idea of a well-understood plain text container for it. Much nicer than wrangling with binary formats like shapefiles, especially when something goes wrong and you're not sure if it's your code (well more precisely your usage of whatever library you've got for it) or the data.

One should be aware that Google, even though JSON is JSON, would sometimes use its own binary encoding for the content of polylines and generally large sets.

Looks like what any sensible dev would come up with if asked to "return this geo data as json". I like simple!

The properties key is plural but contains a dictionary. Does the schema allow for this to be a list?

vega-lite supports rendering of GeoJSON via 'geoshape'

https://vega.github.io/vega-lite/docs/geoshape.html

nice and simple, great. but because it's json, most parsers are horribly inefficient, which is tough, because a lot of geodata is massive.

To add a bit of negative here: the format is incredibly inefficient in JS, because each point gets expanded into a full-blown JavaScript object.

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.

Recently I got into cartography software for a bit and the horrors of the data formats in this industry are real. Feels like everyone under the sun has their own.

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.

Also, JSON! Wow.