GeoJSON
47 points
by tosh
4 hours ago
| 15 comments
| geojson.org
| HN
phillc73
8 minutes ago
[-]
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...

reply
DarkNova6
47 minutes ago
[-]
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!

reply
nobleach
41 minutes ago
[-]
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.
reply
jtbaker
17 minutes ago
[-]
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.
reply
Waterluvian
1 hour ago
[-]
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.

reply
papercrane
1 hour ago
[-]
> 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.

reply
sam_lowry_
1 hour ago
[-]
> tens of thousands of warehouse robots

Sounds like Amazon

reply
Waterluvian
1 hour ago
[-]
Definitely not Amazon. Yuck.
reply
jackconsidine
1 hour ago
[-]
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.

reply
korkoros
1 hour ago
[-]
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?
reply
jackconsidine
1 hour ago
[-]
Excellent question it certainly does come up. Practically speaking the more populous zip codes are all accounted for and that’s where the vast majority of deliveries go to. For example I took the census zip code data 150 miles (crow flies) outside Philly and found virtually 100% coverage.

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

reply
biosboiii
23 minutes ago
[-]
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.

reply
ragebol
1 hour ago
[-]
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...

reply
michaeljhg
1 hour ago
[-]
reply
thibautg
1 hour ago
[-]
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...

reply
Zambyte
42 minutes ago
[-]
Also https://github.com/timescale/timescaledb

I've found it very useful for storing geospatial data over time.

reply
dnnddidiej
22 minutes ago
[-]
Looks like what any sensible dev would come up with if asked to "return this geo data as json". I like simple!
reply
sam_lowry_
2 hours ago
[-]
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.

reply
flir
27 minutes ago
[-]
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.

reply
rippeltippel
1 hour ago
[-]
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.
reply
CamouflagedKiwi
1 hour ago
[-]
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.
reply
trgn
34 minutes ago
[-]
nice and simple, great. but because it's json, most parsers are horribly inefficient, which is tough, because a lot of geodata is massive.
reply
mtucker502
1 hour ago
[-]
The properties key is plural but contains a dictionary. Does the schema allow for this to be a list?
reply
kijin
41 minutes ago
[-]
Nope, properties must be an object (dictionary or null). Which means each property can only appear once.

The spec doesn't say what type the value of a property can be, though. Page 6 of the RFC shows a nested object, for example. So you could probably put a list in there 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.)

reply
tosh
1 hour ago
[-]
vega-lite supports rendering of GeoJSON via 'geoshape'

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

reply
vortegne
1 hour ago
[-]
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.

reply