[Zope] searching by miles from __ zip code----updated to: getting list of zip codes in x miles radius

J Cameron Cooper jccooper@jcameroncooper.com
Thu, 12 Jun 2003 15:44:10 -0500


>  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