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

41–50 of 78 posts

Re: GeoJSON

#41

Post by pramsey »

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…

GeoJSON is not TopoJSON. Saying that is "falling down" is like criticizing a zebra for not being a giraffe. GeoJSON is a mapping of the (non-topological) "simple features" model into JSON, full stop. It does that fine.

Re: GeoJSON

#43

Post by pramsey »

thibautg wrote: post #17
michaeljhg wrote: post #6

Also https://postgis.net/

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

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

Re: GeoJSON

#44

Post by cogman10 »

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.

Re: GeoJSON

#45

Post by matt-p »

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…

OK, I had not considered just using GeoJSON for my flatland CRS (indoor routing). Quite obvious in hindsight, thank you.

Re: GeoJSON

#46

Post by doginasuit »

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…

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.

Re: GeoJSON

#47

Post by larodi »

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.

Re: GeoJSON

#50

Post by qurren »

sdenton4 wrote: post #40
echoangle wrote: post #38

Earlier quoted context omitted.

How is that a geojson problem? If your dataset is correct, adjacent borders will just use the same points and will match exactly.

The problem is simplification. Suppose two regions share a border with some nonlinear points a, b, c, d. Simplifying the polygon for the first region might yield a, b, d while the second yield a, c, d. This creates gaps or overlaps between the two regions.

But what is the border? Set the border to what it actually is, not a simplification of it. The state of Colorado is formally a 697 sided polygon, don't simplify it to a rectangle.
Post reply on HN