Hacker News new | past | comments | ask | show | jobs | submit
bordercontrol | on: USPS now offers official ZIP Code boundary polygons
As someone who has worked with geodata quite a lot, that wouldn't be a good idea in terms of resource usage. You are blowing up the size of the dataset by one or two orders of magnitude. Maybe even more. Processing these polygons would be extremely annoying.

I once built an interactive map for some areas in Switzerland with postcodes rendered on it. I had to use a lot of tricks to keep it down to a few hundred KB for just about 5% of Switzerland's area. If I tried to add more areas, I'd have to abandon the approach of rendering polygons directly with Leaflet and move to static, pre-rendered images. Now, if you add 10 or 100 times more points, you would barely be able to render it fast enough on the CPU anymore.

So, nice idea, but the polygons become hard to work with then.

dmtry | parent | next
It's become much easier to do this with the advent of tiled vector data and libraries like https://github.com/maplibre/geojson-vt

Here is an example using Mapbox GL - https://demos.mapbox.com/boundaries-explorer/?country=US&lay...

bordercontrol | root | parent
Thank you for the links. The postcode project I mentioned was 5 years ago. So this definitely didn't exist back then. Great to see such progress with these libraries.

Quite something to see this in a browser on my phone, rendered that easily. I can clearly remember how hard this was back then.

jaggederest | parent
I'm confused, we did this on US Tiger line file data in 2006, rendering it on a early equivalent of Google Maps. You have to decimate the polygons to get them to render but doing bounding boxes around postcodes is fairly reasonable.

I think the one I enjoyed the most was a zipcode with 38 separate geographical areas, and the other example was a street where one half was one zip code, and the other was a different one, but half way down the street they swapped sides. Representing that with non-overlapping polygons was impossible. So we just let them overlap and shrugged.

bordercontrol | root | parent | next
I was talking about runtime rendering. It's a bit of a hard topic to talk about, as there are a multitude of use cases and approaches.

But in general, having more points really doesn't help with processing geo data. As you said yourself, you had to decimate the polygons. It's always compute vs. precision.

labcomputer | root | parent
> Representing that with non-overlapping polygons was impossible. So we just let them overlap and shrugged.

Yup, lots of weird edge cases. For that one, you could also represent it with a multipoly.