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

51–60 of 78 posts

Re: GeoJSON

#51

Post by tomrod »

qurren wrote: post #50
sdenton4 wrote: post #40

Earlier quoted context omitted.

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.

This is not what OP is describing. It is very common to simplify objects for decreasing boundary objects by orders of magnitude. GeoJSON is missing correlation when you do that. Simplifying country objects from a GeoJSON source could lead to a gap between the country borders. So you either have poor representation or a longer pipeline to convert objects to an amenable object set. It also breaks idempotency in some regards.

Re: GeoJSON

#52

Post by tomtomtom777 »

phillc73 wrote: post #28

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

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

Re: GeoJSON

#53

Post by echoangle »

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.

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.

Re: GeoJSON

#54

Post by echoangle »

tomrod wrote: post #51
qurren wrote: post #50

Earlier quoted context omitted.

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.

This is not what OP is describing. It is very common to simplify objects for decreasing boundary objects by orders of magnitude. GeoJSON is missing correlation when you do that. Simplifying country objects from a GeoJSON source could lead to a gap between the country borders. So you either have poor representation or a longer pipeline to convert objects to an amenable object set. It also breaks idempotency in some re…

To do the simplification, you detect shared borders, simplify and generate polygons again. That doesn’t make topojson inherently superior. You can convert back and forth and for many applications geojson is easier to process.

Re: GeoJSON

#56

Post by drewda »

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.

Yup, technically speaking if the coordinates aren't in WGS84, it isn't GeoJSON

Re: GeoJSON

#57

Post by AlotOfReading »

qurren wrote: post #50
sdenton4 wrote: post #40

Earlier quoted context omitted.

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.

The Texas border with Mexico is formally down the centerline of the Rio Grande, even as the river moves (ignoring fiddly complications). Even if you could somehow take a perfect snapshot of it at a given time, you'd run into the coastline paradox when sampling it.

Re: GeoJSON

#58

Post by NelsonMinar »

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…

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.

Re: GeoJSON

#59

Post by steve-chavez »

pramsey wrote: post #43
thibautg wrote: post #17

Earlier quoted context omitted.

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.

Many 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/f1d0e8ea2266077d...

[2]: PostGIS has https://postgis.net/docs/AsTopoJSON.html but it doesn't take a record.

Re: GeoJSON

#60

Post by [deleted] »

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…

[deleted]
Post reply on HN