Re:USPS now offers official ZIP Code boundary polygons
by labcomputer on Monday November 09, 2026 @07:25PM
(#50434439)
> 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.
Re:USPS now offers official ZIP Code boundary polygons
by bordercontrol on Tuesday November 10, 2026 @04:38AM
(#50437993)
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.
Re:USPS now offers official ZIP Code boundary polygons
by jaggederest on Tuesday November 10, 2026 @03:52PM
(#50446174)
Well, we did it real time using VML in IE6 of all things, and we used adaptive decimation based on the zoom level, so from a practical perspective there's no point in rendering subpixel detail levels
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.