Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GeoJSON

geojson.org

Post reply on HN
Print view View original

71–78 of 78 posts

Re: GeoJSON

#71

Post by echoangle »

rented_mule wrote: post #70
echoangle wrote: post #53

Earlier quoted context omitted.

So don’t simplify the shapes on their own. Geojson is a storage and exchange format, you can still convert it to other formats if you want to modify it.

I think what the original comment is pointing out is that GeoJSON lacks a concept of a shared boundary. Shared boundaries expressed in GeoJSON get around that by duplicating data. Whenever data is duplicated, there's a risk that the copies will not be exactly the same. That makes the task of modification more challenging given that the real world is full of messy data, like duplicates not matching. 20-25 years ago I…

Sure, but not every format is useful for everything. Geojson is great if you want a simple way to express a shape to show on a map. It’s like criticizing CSV because people put strings in choice value fields instead of doing a foreign key to another table. That’s just not what the format is used for.

Re: GeoJSON

#72

Post by CornCobs »

papercrane wrote: post #14
Waterluvian wrote: post #8

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 car…

> 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.

Yes, 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.

Re: GeoJSON

#73

Post by Waterluvian »

CornCobs wrote: post #72
papercrane wrote: post #14

Earlier quoted context omitted.

> 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.

Yes, 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.

Coordinate systems and projections are one of those deeply complicated truths that makes such a headache in GIS. I still shudder at all the pain in school and at previous jobs dealing with inconsistent datasets.

It seems like they decided to just opt out of trying (see the yellow box in section 4): https://stevage.github.io/geojson-spec/#section-4

I think they should have completely backed off from touching on projections and datums in the format altogether. Ie. Something like, “coordinates are 2 or 3 tuples where the values in order correspond with easting/long and northing/lat and elevation/altitude. See metadata for agreed upon units and CRS/projection semantics. It is strongly encouraged to standardize on WGS84 when encoding data with an earth-resolvable datum.”

Because GeoJSON otherwise works fine for indoor spaces, video game spaces, fictional lands, other celestial bodies, etc. You just have to educate on the idea that there’s more to data compatibility than it being GeoJSON.

Re: GeoJSON

#74

Post by rented_mule »

echoangle wrote: post #71
rented_mule wrote: post #70

Earlier quoted context omitted.

I think what the original comment is pointing out is that GeoJSON lacks a concept of a shared boundary. Shared boundaries expressed in GeoJSON get around that by duplicating data. Whenever data is duplicated, there's a risk that the copies will not be exactly the same. That makes the task of modification more challenging given that the real world is full of messy data, like duplicates not matching. 20-25 years ago I…

Sure, but not every format is useful for everything. Geojson is great if you want a simple way to express a shape to show on a map. It’s like criticizing CSV because people put strings in choice value fields instead of doing a foreign key to another table. That’s just not what the format is used for.

I'd take your point further... No format is useful for everything. But we have to be aware of the trade-offs of each format (or language or tool or ...) in order to make the right choice of what to use for a given use case. We do that by sharing knowledge of where a given tool succeeds and where it falls down. Pointing out something a format doesn't handle well is not condemning that format for all use cases (I happily choose GeoJSON over other formats for many things).

Re: GeoJSON

#75

Post by dinkumthinkum »

cogman10 wrote: post #44

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…

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.

https://geojson.io

Re: GeoJSON

#76

Post by wodenokoto »

jackconsidine wrote: post #3

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 v…

How did geojson make this easier than .wkt or .csv with a geometry field?

Re: GeoJSON

#77

Post by sureglymop »

DarkNova6 wrote: post #19

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 li…

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.

Re: GeoJSON

#78

Post by perrygeo »

Stratoscope wrote: post #29

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 y…

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.

Post reply on HN