This is interesting. For a long time it was pointed out that ZIP codes, unlike say, city or state boundaries, were not properly representable as polygons, since they don't divide up acreage into zones, but rather label postal delivery routes. Suppose I build a new neighborhood way out in the middle of nowhere. The "polygon" concept suggests that we could look and see what polygon I'm in, and that will determine what post office delivers my mail. But in reality, if there was no route to that area already, they could decide to make it part of any one of the surrounding routes.

I suppose though, as long as you let the polygons map has uncontained areas, where no routes currently exist, it's a doable task to draw polygons around the limits of every route network, as long as you don't mind that they may have lots of weird ragged edges.

▲

bordercontrol an hour ago | parent | next [-]

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.

	▲	jaggederest a few seconds ago \| parent \| next [-]
		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.
	▲	dmtry 16 minutes ago \| parent \| prev [-]
		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...

▲

mikepurvis an hour ago | parent | prev | next [-]

Making each able to be a union of multiple enclosed areas would probably also help add an axis of flexibility.

▲

clickety_clack 44 minutes ago | parent | prev | next [-]

Doesn’t that imply that a ZIP code could change if the route is changed?

	▲	NegativeLatency 42 minutes ago \| parent [-]
		Only if it’s 1:1 instead of many to many

▲

montroser an hour ago | parent | prev [-]

Yeah, I always thought that was a bit of an aCkTcHUuaLly type of point. Okay, okay, it's about routes. But, when you can draw perfectly mutually exclusive convex hulls around the unions of the lots receiving mail for a given zip code, then you can draw zip code polygons.