Thanks for the thought on this. I realized that what I really need is a return of all of the zip codes within x miles of a zip code. In other words, show me all records (from zcatalog or sql) which match the results of a radius search where zip codes in the radius are returned.
I'm reminded of a digital logic design class I once took. We had a problem where given a certain set of inputs, we had to calculate the outputs. It was to be done in a single (small) programmable chip. Being a software engineer, I did my state diagrams and whatnot, came up with the logical formula, and put together the gates that solved the inputs as they came through. A friend of mine, being of a more practical mindset, solved all the states himself and made what was basically a lookup table. It fit in the chip, and produced exactly the same outputs. What's more, it took a lot less work on his part. My solution may have been more elegant, but given the nature of the problem I'm convinced his was the better solution. What's my point? There's a fixed and not-too-large number of post offices. Make a table of the distances between all pairs of POs (or ZIP code centers), sort of like the cities table on a road map. I'm not exactly sure how big this'll be, but I'll bet it's not that big in modern computing's scope. You could use a sparse table and only include those pairs within a 'reasonable' distance. Then, given a post office, get the column of the distance to all others and return the zip codes of those within your range. Your table can be generated by whatever method is easiest to you (probably an existing geo-manipulation package), and I bet lookup will be a lot faster (and easier to write) than computation. By "table" what do I mean? Doesn't matter to me: a global Python array (in memory), a ZODB bag of tuplish objects, or a relational database could all do the job. --jcc