Instead, what they are, are collections of mail delivery points. The "full" 5+4 zip code represents one mail delivery route that a postman follows to deliver mail. And the "fuller" 5+4+2 zip code has the last two digits of the street number.
So couple issues with trying to make polygons from zip codes:
1. There is no guarantee that a given zip code has a finite area. There are several zip codes that exist at a single street address. So... is that a point? Is it the footprint of the building where the mail is delivered? Maybe a hexagon with some minimal side length? Examples: Several IRS return addresses, and some large hospitals.
2. There is no guarantee that a given zip code has a contiguous polygon representation. It depends on the algorithm you use to generate polygons from address points.
3. There is no guarantee that a given zip code has a fixed geospatial representation. Example: the armed forces zip codes for delivering mail to overseas personnel on deployment. The AFPO zips represent "wherever the troops happen to be today". How do you represent that as a polygon?
This is why the USPO has long resisted publishing polygons. It doesn't make sense at the conceptual level, so there are a bunch of weird edge cases you wouldn't expect if you naively treat them as polygons.
ALSO: The census does publish zip polygons. Some of those have zero people living in them (like the hospitals and IRS locations), so you can get weird div-by-0 effects if you aren't careful.
APO/FPO is a good counterexample, though even these presumably have domestic delivery points where the postal service hands off mail to the military (not that their locations should matter to postal customers).
Same goes for DPO addresses, I assume USPS doesn't actually deliver to embassies overseas (or at least does so under contract with the State Department if it does, and again consolidates deliveries at one or more domestic locations).
1. A given land parcel may not have mail delivery (think: rural land, even with people living on it), so... what is its zip code? Does it even have a zip code? Remember, a zip code is defined as a set of mail delivery points.
2. A given land parcel may have multiple mail delivery points, each of which may have a different zip code (think: a large mall or commercial building with multiple tenants, where it may be more convenient for the USPS to deliver from two or more mail routes). Does that land parcel have more than one zip code or do you arbitrarily pick one? If it has more than one, does the whole parcel have both codes (so, overlapping polygons), or do you try to subdivide it somehow?
[Users of zip code polygons often want to preserve the capability to look up the zip code from a given lat/lng point. So they will yell at you if you choose to have overlapping polygons or two zip codes for one polygon.]
3. What about AFPO addresses that represent the current location of a group of people who move around all the time? An aircraft carrier out in the Pacific is not near any land parcels.
But polygons support it fine, they just overlap.
"Many postcodes for particular lat/lon" should be part of the polygon delivery schema, i.e. you get a list all the time.
Seems like a non-issue for most use cases.
> 2 means some polygons overlap which is fine too
For some use-cases, sure, but not all. One common use-case for zip code polygons is "I have a lat/lng, just give me the zip code, damnit!" Your users might expect that a lat/lng point can have no zip code, but most won't expect that it can have multiple (because no address has multiple zip codes).
At a minimum that leaves you scrambling to explain "well, but it only happens in a few edge cases where a land parcel has multiple mail delivery locations from different postal carriers, and it's super-rare, pinky swear".
> 3 means some zipcodes are excluded from scheme, as one might not be legally allowed to know where a particular unit is.
Another very common use-case for zip code polygons is "I have a zip code, just tell me where it is, damnit!" Maybe they want to estimate shipping distance without hitting the shipper's API.
Part of the problem here is that the AFPO zips do have a physical location for this purpose, which is the facility where mail and parcels are delivered from the USPS to the AFPO. And your users will probably expect you to know that's what they mean. So when you try to explain that "actually an aircraft carrier is constantly moving and we're not allowed to know where it is", they will think you are being pedantic and condescending, and look for someone else to sell them polygons.
But let's say the user actually wants to forecast sales of the new ThingyWidget 3000 by estimating the average weather by customer zip code (by getting the polygon for each zip and the doing a spatial join to weather data). When they do that for the AFPO drop-off point, they're going to get a completely wrong estimate of the weather because the people receiving mail at the AFPO zip are not physically present at that place. So when you explain that "actually that is the physical location of the AFPO facility" they will also think you are being pedantic and condescending, and look for someone else to sell them polygons.
Notice how you're damned if you do and damned if you don't?
Any choice you make for polygonalizing zip codes will be wrong for some use case, and it will be spectacularly wrong for certain edge cases in very intuitive ways that certain users deeply care about and will blame you for.
Which brings me back to the point: You can make a set of polygons for zips which is "good enough" for many use-cases, but ultimately you cannot represent zips as polygons in a way that is suitable for all use cases because, once again, zip codes are not polygons!
If I was developing something that required dealing with US GIS I'd very much prefer a service that does the above, and handle the edge cases, than have no such service at all.