No, it's a more fundamental problem: Zip codes are not "areas" and have no boundary.
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.
Oh, I meant the PostGIS "polygons" which can have holes in them. So #1 I believe they just had a small polygon, #2 was no problem, #3 wasn't supported but whatever. The polygons did overlap too.
I suppose it's a polygon, but my PO Box has its own ZIP+4.
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.
So 1 means the polygons don't cover the entirety of the US which is fine, 2 means some polygons overlap which is fine too, 3 means some zipcodes are excluded from scheme, as one might not be legally allowed to know where a particular unit is.
"Many postcodes for particular lat/lon" should be part of the polygon delivery schema, i.e. you get a list all the time.
Ok, but you have to think about how people actualy use the polygons you create. You might be assuming these are minor edge cases or that I have enumerated all of the relevant edge cases (I have not) and that we can sweep this in a corner and forget about it.
> 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!
Well the alternative to "here's a service that converts a zipcode to a polygon, and coordinates to a list of polygons, and here's the fine print of limitations and how they are communicated" is declaring that postcodes are arcane entities and their connection with the mortal plane is only an illusion, and no such service is possible.
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.
I was in case #2 for a while, and tbh it should be treated as the building's fault for being this way, cause ambiguous ZIP codes aren't really supported. The IRS refused to send my refund, mail kept getting lost, and various things involving credit kept flagging me for fraud. Also it looked like a PO box to some systems but wasn't. My solution was to move, or I could've gotten an actual PO box or other mailing address.
Like most large data sets, ZIP codes are complicated. They are defined by delivery routes, so sometimes they overlap when that makes sense for delivery purposes. Some post offices with a lot of P.O. boxes can have their own ZIP code and that's typically represented as a point rather than a polygon. Large naval vessels have their own ZIP+4, and the base 5-digit ZIP code is a single point that is the land-based processing facility that the vessel is associated with. The same for some other types of military facilities and government buildings (e.g., the Pentagon and White House). I'm sure there are more special cases. It would be interesting to know how accurately the official data being offered here handles all this.
I came across all this when building maps for sales territories defined by ZIP codes. I needed to have a simple, clean partitioning of the US for this use case, and ZIP codes are not that. So I took all ZIP codes as points and generated a Voronoi diagram to yield clean, non-overlapping polygons that covered every point in the country. That was plenty good for the purposes of doing visualizations of the US split into tens of territories.
It took a bit of scrolling to finally find someone who understands that in most countries postalcodes can be rendered as areas — if you have the points of each address, using them to generate a Voronoi diagram.
How was it "against their consent?" The Siri AI / Apple Intelligence feature required a user to explicitly enable it. It didn't just get enabled for you.
I know this because I just explicitly enabled it, and now I have the new Spotlight search. I didn't have it before I enabled it.
No, this is downloaded and installed upon installation of MacOS 27. The 30 GiB of "Apple Intelligence" is sitting on my disk against my consent. I've even taken pains to do all of the hacks (save for the novel one in this repo) to disable Siri AI.
You are delegating work and reviewing delegated work, but not managing. No performance coaching, no career development, no mentoring, no conflict resolution, no influencing opinions, and on and on.
So it looks like you're doing all the management work required by your reports, and if your reports were more capable you'd need to do more of the other things mentioned as well.
My original comment was to signal that if all you do now is write descriptions to feed to agents then you're not a programmer any more but you've become a manager as what you're doing is a management role and not an artistic or engineering one. You've changed jobs and you should be fine with that, just acknowledge it and move on, but stop fooling yourself that you're still a programmer or engineer. You're not, you're a manager now, even if you're not doing most of the things required of a people manager, as in your comment.
That's silly. You may as well say Santiago Calatrava isn't an architect any more because he's delegating the vast majority of the architecture work for his projects.
Maybe, because I personally enjoy Emacs, but Babel cannot gather code from external files into a single place and then keep them in sync. org-babel can "tangle" source code blocks into an outside source files, but this makes the org document the authoritative source and pushes it outwards. I want something that treats the actual source code as the authoritative source. (I haven't actually used "tangle" though, so I'm open to correction.)
And no, because Emacs isn't going to be popular enough to be widely used.
> Babel cannot gather code from external files into a single place
Yes it can. org-babel-detangle copies edits you make in a tangled file back into the matching source blocks in the Org file. There's also `#+INCLUDE: "file.py" src python :lines "10-40"` and org-transclusion package - `#+transclude: [[file:foo.el::some-defun]] :src elisp` shows live content from an external file in the Org buffer.
Babel has no built-in way to import arbitrary existing files, but for the stuff that you make it make sense, it knows how to get its shit together back into one place.
I read your book when I was ten years old! I was later stoked to find our computer system at school was a Unix machine, so I could try some of the commands you explained in the story, like ps and sendmail.
Dang, my bad. Thought I cleaned that up. To be clear, I use AI to help clean up scattered thoughts, and then I edit it further but sometimes I miss the AI-isms that it inserts.
Unfortunately I think that we need to be much more judgmental than is tolerated on this forum if we want to get people to stop writing with AI assistance.
People are not going to stop spamming you with slop text unless the narrative is "Using AI for writing is a mark of poor literacy/low intelligence".
I had an argument with Steve Jobs about pie menus at the Educom conference in Washington DC, October 26 1988 -- right after he finally shipped NeXTSTEP (people had been teasing it as vaporware with "NeVRSTEP" t-shirts).
I was demonstrating the work I'd done at the UMD Human Computer Interaction Lab on a color Sun 3/60 that Sun lent me to use at their booth, which happened to be right across from the NeXT booth.
Ben Shneiderman dragged Steve Jobs over to the Sun booth, and I gave him a NeWS demo for about half an hour: HyperTIES, UniPress Emacs, pie menus, PostScript windows in arbitrary shapes — the Hubble Space Telescope in orbit, Bill Joy's head popping up when you pointed at it, that kind of thing. Jobs has RELIGION about UI, and he argued wonderfully. He also has volume. On the show floor, in a suit and tie, he was jumping up and down yelling:
"That sucks! That sucks! Wow, that's neat! That sucks!"
Not discouraged, I figured one neat to three sucks was a good score from Steve Jobs. When I explained how flexible NeWS was -- programmable PostScript in the window system, malleable windows, extensible UI, transforming all menus of all apps into pie menus, etc -- he told me:
"I don't need flexibility -- I got my window system right the first time!"
Okay, agree to disagree. Then I gave him a free NeWS "NeRD" button, which he gracefully accepted, then he departed leaving my reality intact and undistorted.
So empthought's joke isn't far from the design philosophy. NeXT was world-class software, but malleability for the user was exactly what Jobs was proud of not offering. That's a big part of why the Emacs / NeWS / PostScript / Smalltalk / Self / Oberon / JavaScript / AJAX branch of computing and the Mac / NeXT / Display PostScript / Objective C / Cocoa branch diverged.
Also, during the conference I was giving essentially the same rolling demos to anyone who walked by, and some scruffy looking dude was hanging out and watched the whole series until it looped back to Emacs, then he finally remarked "I used to use EMACS on ITS." (i.e. the original TECO version)
...I said "Wow, what was your user name? Mine was A2DEH@AI!" and he replied "WNJ".
Only then did I realize I had been giving demos to Bill Joy, the author of VI, of UniPress Emacs for NeWS, and of HyperTIES embedded graphical pop-up links demo with his own inflatable pop-up head. I didn't recognize him because he'd shaved his beard!
reply