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

31–40 of 78 posts

Re: GeoJSON

#31

Post by Demiurge »

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…

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

Re: GeoJSON

#32

Post by jvanderbot »

Demiurge wrote: post #31
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…

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

Right. Encoding a union algorithm into the data structure just introduces the reverse problem: Selecting a subset now requires extra logic beyond jq.

Re: GeoJSON

#33

Post by ryandrake »

jackconsidine wrote: post #16
korkoros wrote: post #7

Earlier quoted context omitted.

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?

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’r…

No 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!

Re: GeoJSON

#34

Post by jeffbee »

trgn wrote: post #23

nice and simple, great. but because it's json, most parsers are horribly inefficient, which is tough, because a lot of geodata is massive.

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

Re: GeoJSON

#36

Post by trgn »

jeffbee wrote: post #34
trgn wrote: post #23

nice and simple, great. but because it's json, most parsers are horribly inefficient, which is tough, because a lot of geodata is massive.

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

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

Re: GeoJSON

#37

Post by heed »

ryandrake wrote: post #33
jackconsidine wrote: post #16

Earlier quoted context omitted.

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’r…

No 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 tradeoff…

imo 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

Re: GeoJSON

#38

Post by echoangle »

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…

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

Re: GeoJSON

#39

Post by nobleach »

jtbaker wrote: post #27
nobleach wrote: post #22

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.

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.

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

Re: GeoJSON

#40

Post by sdenton4 »

echoangle wrote: post #38
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…

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.
Post reply on HN