Let's see. Without looking hard, no strict, uses cgi-lib.pl, makequote reinvents DBI's quote method (badly - and if you did this in Oracle then you'd want to use placeholders, really), there is a horrible parsing technique, no indentation, method calls inside of strings (that won't work very well), the aforementioned zip code issues and his formula for distance is computationally unstable at low distances (which is ironically where you care most about accuracy). I also think that the formula should be documented in the code...

But other than the fact that every detail sucks, the general idea is workable.

If you want a better calculation, then I'd suggest using Haversine's formula (faster for computers to calculate, more numerically stable):

\ndlon = lon2 - lon1\ndlat = lat2 - lat1\na = (sin(dlat/2))^2 + cos(lat1) * cos(lat2) * (sin(dlon/2))^2\nc = 2 * atan2(sqrt(a), sqrt(1-a))\nd = R * c\n

where R should be the radius of the earth, aka 3,959 miles (on average - it varies). You can find a derivation at [link|http://mathforum.org/library/drmath/view/51879.html|http://mathforum.org...h/view/51879.html].

Also given how many services (Google, mapquest, etc) do accurate geocoding, I'd suggest that today the zip code approximation is not good enough. Sure, use it as a fallback. But go negotiate a contract with someone like mapquest allowing you to geocode lots of addresses. I don't know what it costs, but I don't think it is that much. And take your program and add an artificial limit, such as "closest 3 within 20 miles". (Or reorganize it about that limit) Who's going to drive more than that just to get to a dealer? That limit will let you use a "bounding box" of latitude/longitude combinations allowing you to significantly reduce how many dealers you have to do the expensive calculation for.

Have I explained my response sufficiently? The idea works. The approach is inefficient. The code is crap.

Cheers,
Ben