Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.
by sam_lowry_ - What a great project.
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.
by flir - Nice work with mxmap. It's a very good way to appreciate to what extent EU depends on US - email providers being just one of several dimensions.by rippeltippel
- 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.
by cogman10 - This is just pretty wrong. Sure, geojson can be bloated but it is not for "no benefit." It is a very popular format and it is easy to encode and decode, even if it is slow for large data. It is more for sharing than long term storage. Take a site like below, it is very convenient to render json this way.
- > 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.
This is a fair critique, however, for any large GeoJSON, the coordinate arrays will dominate the size. I think it's also safe to assume this data will be gzipped at rest and over the wire, which will eliminate most of the "header" metadata size you mention. As you point out, it would be much more efficient to have a binary format, and there are good examples like these, that are ~2-3x smaller in benchmarks:
https://flatgeobuf.org/ https://github.com/mapbox/geobuf
That said, I think GeoJSON should be compared against other human readable formats like KML, which has a lot of wasted space as well, while being more difficult to read/write.
- Do you mean geocoordinates when you say not human readable? Those are obviously at the heart of geospatial information but there is quite a bit more to the spec that does benefit from being human readable, and I'd include longitude/latitude among them. There are also solutions like cbor which allow them to be transferred and decoded/encoded from binary. For performance critical data you can also use something like protobuf, but it would be a huge pain to handle everything that way. Json is a great choice as a general spec.by doginasuit
- 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.
by vortegne - Somewhat related: Falsehoods Programmers Believe About Map Coordinates: https://news.ycombinator.com/item?id=24659039by layer8
- Also https://postgis.net/by michaeljhg
- Also https://github.com/timescale/timescaledb
I've found it very useful for storing geospatial data over time.
by Zambyte - And with PostgREST [0], you can automatically convert any PostGIS table (with geometry or geography column) to GeoJSON by using an "Accept: application/geo+json" header in the request.
[0] https://docs.postgrest.org/en/v14/how-tos/working-with-postg...
by thibautg - 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...
by ragebol - 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.by nobleach
- Dang, fun memories of when I was first getting in to geo/data stuff and doing a lot of web mapping stuff with D3, Leaflet and friends. Seems as tools like Vector tiles/PMTiles have supplanted topojson for a lot of visualization oriented use cases.by jtbaker
- Made by Sean Gillies and a few others. Back when mapbox was doing all sorts of great open source stuff. Legendsby cr125rider
- 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.
- How did geojson make this easier than .wkt or .csv with a geometry field?by wodenokoto
- About 25% of ZIP codes don't have a corresponding Census Bureau ZCTA, for example 10118. Do you end up needing special handling for those cases? Or has it not yet come up in practice?by korkoros
- 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!
by DarkNova6 - I'm glad there are sqlite backed file formats in that space. Having that said, they're not always the ideal choice.
For example, for map tiles mbtiles (sqlite) files can be used. In many applications though, pmtiles files are better because they allow for http range requests.
by sureglymop - 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.
by Waterluvian - > tens of thousands of warehouse robots
Sounds like Amazon
by sam_lowry_ - OK, I had not considered just using GeoJSON for my flatland CRS (indoor routing). Quite obvious in hindsight, thank you.by matt-p
- > 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.
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.
by papercrane - 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!
by Stratoscope - I like TopoJSON and have used it in projects. But it's weird to set it up as opposition to GeoJSON. It's a complement. GeoJSON is a general data format meant to replace uses of ESRI Shapefiles and other complex formats. TopoJSON is more of a solution for a particular application need.
Is there much work developing or using TopoJSON these days? I haven't seen much about it in a few years.
by NelsonMinar - Partly true, but don't blame GeoJSON. Blame the data model.
GeoJSON is firmly rooted in the "simple features" model of spatial data. Sometimes called the "vector data model", this is ubiquitous in GIS. Each geographic entity (aka "Feature") has a single geometry and many non-geometry attributes. Each feature is independent.
The vector data model (for better or worse) is the basis of many systems because it fits the tabular/relational style so closely. What is a feature but a row in a table plus a special column describing its geometry? Topological relationships are ignored by design.
TopoJSON, ESRI coverages, the internal OpenStreetMap data model, and a few others are notable exceptions. They explicitly handle spatial relationships, at the cost of making the model unintelligible to row-based processing.
by perrygeo - How is that a geojson problem? If your dataset is correct, adjacent borders will just use the same points and will match exactly.by echoangle
- Is this actually GeoJSON falling down, or decades of convention extended to JSON? Topology is great, but it is sidestepped by Shapefile/WKT/WKB/etc, in favor of independent primitives like POINT, LINE, POLYGON. If GeoJSON did not exist as a new JSON GIS data format encoding these primitives, TopoJSON would not have "replaced" it, due to the added mis-match with other non-topological formats.
From what I can tell, the top criticism of GeoJSON is the under-enforced winding order specification, and crossing the antemeridian.
by Demiurge