5 ms·
GeoJSON
- sam_lowry_ 6mo agoDunno 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.
- rippeltippel 6mo agoNice 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.
- flir 6mo agoWhat 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.
- jackconsidine 6mo agoGeoJSON 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/master/il_illinois_zip_codes_geo.min.json https://github.com/OpenDataDE/State-zip-code-GeoJSON/blob/ma... although you can generate newer versions from the last census.
- korkoros 6mo agoAbout 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?
- jackconsidine 6mo agoExcellent 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
- ryandrake 6mo agoNo shade whatsoever at you or your business: I'll say upfront that you certainly made the right practical decision for the goal of running a business. 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!
- heed 6mo agoimo it's not a great solution. the problem is there is no standard or source of truth for zip code boundaries because they are a usps concept used for mail logistics. zip codes change all the time, are approximations of an area, and generally shouldn't be used for something that requires precision like calculating rates. may be ok to use as a fallback though. also i hear your point on swe roles and don't disagree
- wodenokoto 6mo agoHow did geojson make this easier than .wkt or .csv with a geometry field?
- tosh 6mo agovega-lite supports rendering of GeoJSON via 'geoshape' https://vega.github.io/vega-lite/docs/geoshape.html https://vega.github.io/vega-lite/docs/geoshape.html
- michaeljhg 6mo agoAlso https://postgis.net/ https://postgis.net/
- thibautg 6mo agoAnd 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-postgresql-data-types.html#postgis https://docs.postgrest.org/en/v14/how-tos/working-with-postg...
- pramsey 6mo agoAt the SQL level, the ST_AsGeoJSON(record) variant will convert a tuple that includes a geometry and any combination of other columns into a GeoJSON output.
- steve-chavez 6mo agoMany thanks for your work pramsey. We use that exact function [1], do you have any plans for a similar function for TopoJSON? One that also has a record parameter? [2]. [1]: https://github.com/PostgREST/postgrest/blob/f1d0e8ea2266077d2b57144927dea08bd8f74579/src/PostgREST/Query/SqlFragment.hs#L224 https://github.com/PostgREST/postgrest/blob/f1d0e8ea2266077d... [2]: PostGIS has https://postgis.net/docs/AsTopoJSON.html https://postgis.net/docs/AsTopoJSON.html but it doesn't take a record.
- Zambyte 6mo agoAlso https://github.com/timescale/timescaledb https://github.com/timescale/timescaledb I've found it very useful for storing geospatial data over time.
- pramsey 6mo agoMobilityDB might also be of interest, for people handling trajectories.
- Waterluvian 6mo agoI’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.
- sam_lowry_ 6mo ago> tens of thousands of warehouse robots Sounds like Amazon
- Waterluvian 6mo agoDefinitely not Amazon. Yuck.
- papercrane 6mo 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.
- drewda 6mo agoYup, technically speaking if the coordinates aren't in WGS84, it isn't GeoJSON
- CornCobs 6mo agoYes, they deprecated the CRS field and the current state of geojson handling libraries is pretty messy as a result since geojson does not have versioning! If you have old geojson in a different projection, will your library respect the crs field or will it simply misinterpret your data? Wondering if anyone could shed light on the decision to remove it as a standard when projection seems to be a critical part of GIS.
- mtucker502 6mo agoThe properties key is plural but contains a dictionary. Does the schema allow for this to be a list?
- kijin 6mo agoNope, 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. 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.)
- CamouflagedKiwi 6mo agoThis 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.
- vortegne 6mo agoRecently 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.
- ragebol 6mo agoHave 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...
- volume_tech 6mo ago[dead]
- DarkNova6 6mo agoI’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!
- sureglymop 6mo agoI'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.
- nobleach 6mo agoWe used this extensively when I worked in this space (2010 - 2014). My favorite addition was using https://github.com/topojson/topojson https://github.com/topojson/topojson to add arcs. That cut down on quite a bit of points to represent curves.
- jtbaker 6mo agoDang, 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.
- nobleach 6mo agoI'm gonna have to dive into a rabbit-hole! I was working on an ESRI Shapefile to GeoJson converter back in those days. But D3 and Leaflet were such cool tech! MapBox too. Linking SagaGIS with PostGIS to do pre/post wildfire analysis was my jam.
- trgn 6mo agonice and simple, great. but because it's json, most parsers are horribly inefficient, which is tough, because a lot of geodata is massive.
- jeffbee 6mo agoJSON parsing is probably one of the most thoroughly optimized subsystems in the whole industry at this point. Obviously there are ways to encode the same data that are easier to parse (e.g. instead of absolute floating point coordinates, use integer deltas along a path in some reasonable CRS) but because this inefficient representation is so common and so long-standing the parsing is faster than people think.
- trgn 6mo agothe default parsers all load the entire thing in mem, which is not good. 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.
- kbolino 6mo agoFor whatever it's worth, you don't have to write anything special to handle the reference system, because the final, published version of RFC 7946 only allows WGS84 anyway.
- biosboiii 6mo agoI 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 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.
- dnnddidiej 6mo agoLooks like what any sensible dev would come up with if asked to "return this geo data as json". I like simple!
- phillc73 6mo agoGeoJSON 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/ https://qupath.github.io/ [2] https://github.com/qupath/qupath-docs/blob/main/docs/advanced/exporting_annotations.md https://github.com/qupath/qupath-docs/blob/main/docs/advance...
- tomtomtom777 6mo agoThe spec states: > 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.
- Stratoscope 6mo agoOne 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+polygons&form=HDRSC3&first=1 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 https://github.com/topojson/topojson-simplify https://github.com/topojson/topojson-simplify
- Demiurge 6mo agoIs 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.
- jvanderbot 6mo agoRight. Encoding a union algorithm into the data structure just introduces the reverse problem: Selecting a subset now requires extra logic beyond jq.
- Stratoscope 6mo agoSimilarly, typical map APIs like the Google Maps API accept GeoJSON and not TopoJSON. I was not suggesting TopoJSON as a replacement for GeoJSON, but as a complement to it. With the tools on the TopoJSON GitHub, you can have GeoJSON input and output, but convert to TopoJSON for the simplification step to avoid the "slivers" problem.
- Demiurge 6mo agoAlso, JSON! Wow.
- cr125rider 6mo agoMade by Sean Gillies and a few others. Back when mapbox was doing all sorts of great open source stuff. Legends https://github.com/sgillies https://github.com/sgillies
- cogman10 6mo agoInteresting 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.
- doginasuit 6mo agoDo 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.
- deleted 6mo ago[deleted]
- morganherlocker 6mo ago> 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://flatgeobuf.org/ https://github.com/mapbox/geobuf 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.
- larodi 6mo agoOne 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.
- layer8 6mo agoSomewhat related: Falsehoods Programmers Believe About Map Coordinates: https://news.ycombinator.com/item?id=24659039 https://news.ycombinator.com/item?id=24659039
- jasoncartwright 6mo agoHave 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 https://geojson.page
- kitd 6mo agoThere's a map facility not linked here that allows you to build GeoJSON graphically: https://geojson.io/#map=12.42/51.50593/-0.13003 https://geojson.io/#map=12.42/51.50593/-0.13003
- cyberax 6mo agoTo 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.