This only sets a "bounding box" of zips to consider when doing the actual
queries and calcs.  If you try to do a brute force match over your entire
database, it becomes extremely slow.  So, this query draws (selects) a
square with sides equal to the desired radius, then passes those values to
the queries and calcs that do the real meat of the work.  It doesn't return
the zips in the desired radius, radii being round and all that.  The
distance calcs drop the corners, so to speak, later in the tag.

It's extremely fast in operation - check out
http://www.dbactive.com/tags/radtest.cfm - it output the calc time for each
radius lookup.  Keep in mind that this demo is running on a very bloated
MSAccess DB on a shared hosting server. As an example:

84 Zip Codes within 10 miles of 60601 (CHICAGO, IL):
Processed in: 281 MS

This includes sort time as well (sorted by the distance in miles in this
case).

Based on your example of Alaska, here is an example.  Using 10 miles as the
radius, the system returns:

25 Zip Codes within 10 miles of 99501 (ANCHORAGE, AK):
Processed in: 78 MS

The highest distance returned from the center zip was 8.73 miles.  So, to
check and see if the tag is even fairly accurate, I ran a search at 99
miles:

52 Zip Codes within 99 miles of 99501 (ANCHORAGE, AK):
Processed in: 141 MS

I'll show the three pertinent entries - the aforementioned 8.73 mile zip and
the next two:

99516 ANCHORAGE AK ANCHORAGE 907 8.73

99687 WASILLA AK MATANUSKA SUSITNA 907 12.66

99577 EAGLE RIVER AK ANCHORAGE 907 13.65

So, no other zips within the orignal radius of 10 miles.  The tag seems
fairly accurate.  I'm sure it could be better, but for most locator type
systems it's definately close enough.  It's not doing driving distances,
obviously.





--------------------------------------

jon roig wrote:

> If you're using the JCSM database, here's a simple query to pull out
> all the zips within #radius# number of miles.

> <CFQUERY NAME="findLocal" DATASOURCE="Zip_Search">
> SELECT jcszip.Zip,
> jcszip.LastLineCity,
> jcszip.State,
> jcszip.Lat,
> jcszip.Lon
> FROM jcszip
> WHERE (((jcszip.lat)>= (#geoCode.Lat# - (#Radius# * 0.0005))
>  And (jcszip.lat)<= (#geoCode.Lat# + (#Radius# * 0.0005))
> ) AND ((jcszip.lon)>= (#geoCode.Lon# - (#Radius# * 0.0005))
>  And (jcszip.lon)<= (#geoCode.Lon# + (#Radius# * 0.0005))
> ))
> ORDER BY jcszip.Zip
> </cfquery>

I don't know what area the JCSM database covers, but from the looks of
it I wouldn't count on this code unless it only covers the equator
because the distance between meridians differs with the lattitude. And
if you think the difference is insignificant: chances are your search
area is only 50% of what it should be when doing a search from
Anchorage, Alaska.

Just think of the difference in distance between meridians on the
equator and on the poles. The difference between the 0-meridian and the
1-meridian (either east or west) on the equator is 60 miles (n), and on
the poles they actually overlap.

My trigo is a bit rusty, but I will give it a shot to get the code correct:
distance = acos(cos(latA)cos(latB)cos(lonB-lonA)+sin(latA)sin(latB))/360
* 2 * pi * R
R = radius earth in the appropriate units
lon from -180 to 180 degrees
lat from -90 to 90 degrees

If you are dealing with small distances and don't actually overlap one
of the poles a reasonable approximation would be to compensate only the
longitude by division with cos(#geoCode.Lat#):
SELECT *
FROM jcszip
WHERE (((jcszip.lat)>= (#geoCode.Lat# - (#Radius# * 0.0005))
  And (jcszip.lat)<= (#geoCode.Lat# + (#Radius# * 0.0005))
) AND ((jcszip.lon)>= (#geoCode.Lon# - (#Radius# *
0.0005)/cos(#geoCode.Lat#))
  And (jcszip.lon)<= (#geoCode.Lon# + (#Radius# *
0.0005)/cos(#geoCode.Lat#))
))
ORDER BY jcszip.Zip

(I assume your factor 0.0005 is correct for miles (s).)

Naturally you need to apply the full calculation on the resultset to get
the actual distance, but this first approximation should reduce its size
sufficiently to make that possible.

And for the PostgreSQL users: check /contrib/, this functionality is
built-in to the database.

Jochem



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription: 
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Structure your ColdFusion code with Fusebox. Get the official book at 
http://www.fusionauthority.com/bkinfo.cfm

Reply via email to