In that example, your store database may consist of several dozen to several hundred records (one for each store), and for each record you would have to perform the distance calculation. This is not so bad. But what if you had over 1,000 locations? Or what if you wanted to find all cities located within a particular radius from a customer, regardless of whether or not you have a store there?

In this case, you would certainly NOT want to loop through all cities within your database making the distance calculation. That would take a VERY long time. You might, in a flash of inspiration, attempt to perform the distance calculation only for cities within that customer’s state… but that would not work very well for people who live near a state’s border, or for people who live, say, in Rhode Island.

This article details a method for dramatically reducing the amount of processing necessary to find all locations within a certain radius.

By first performing a rough trim of the cities list based on latitude and longitude, we limit the number of calculations we must make. By using the algorithm below, we can accomplish that, as well as ensure that we are grabbing all cities within a particular area, regardless of state boundaries, etc.

Given a customer’s latitude (iStartLat) and longitude (iStartLong), and the radius we wish to search (iRadius, in miles), the following algorithm will return the latitude and longitude range for cites we will evaluate (using the formula provided in the last article). NOTE: Be aware that — as in the last article — this algorithm is accurate enough for most e-commerce applications, but NOT for navigational applications:

‘ THIS VARIABLE SETS THE RADIUS IN MILES iRadius = 150 LatRange = iradius / ((6076 / 5280) * 60) LongRange = iRadius / (((cos(cdbl(iStartLat * _ 3.141592653589 / 180)) * 6076.) / 5280.) * 60) LowLatitude = istartlat – LatRange HighLatitude = istartlat + LatRange LowLongitude = istartlong – LongRange HighLongitude = istartlong + LongRange

Now you can create a SQL statement which limits the recordset of cities in this manner:

SELECT * FROM Locations WHERE Latitude <= [HighLatitude] AND Latitude >= [LowLatitude] AND Longitude >= [LowLongitude] AND Longitude <= [HighLongitude]

(Note: This algorithm works pretty well for US and Canadian cities. Adapting the algorithm to other regions may require changing the comparison order due to negative latitudes, etc.)

Performing the distance calculation (covered in the previous article) on the resulting recordset ensure that you are not wasting too many CPU cycles on cities that are obviously outside the radius you have specified.

Do you remember sitting in high-school, taking your first trigonometry course, wondering to yourself, “When will this crap ever apply to me in the ‘Real World’?” Well, my friend, today is that day. No, I am not going to make you dig out your old trig textbooks… nor am I going to go into the theory behind how these routines work. After all, these articles are meant to provide quick solutions to real-world problems, not to torture you with the arcana of your teen years.

So let’s just say that these functions are derived from spherical trigonometry, and leave it at that. “But wait,” I can hear some of my geek friends starting to say, “the planet we live on is more of an oblate spheroid, not a perfect sphere.” To which I would say, “That is correct.” I would then probably also add, under my breath, “Get a life,” but that is a topic for another article entirely. These routines should be plenty accurate for the type of applications I mentioned above. In general, you can expect that the distance you receive will average an accuracy of +/- one percent.

The code below includes three routines. The main one, called GetDistance, calculates the distance between two points on the globe. To use it, you must pass the latitude and longitude (in decimal degrees, e.g. 32.9697) of both points. You also pass the unit of measure that you’d like the results returned in, either ‘K’ for kilometers, ‘M’ for statute miles, or ‘N’ for nautical miles.

Here is an example of the output produced by the code below:

Calculating the distance between Dallas (75248) and San Antonio (78201) 262.513422981729 Miles 422.474402195107 Km 228.117927751138 Nautical Miles Dallas’ decimal latitude of 32.9697 can also be shown as 32° 58′ 10″

At this point, you may be wondering how to obtain information such as latitudes and longitudes for various points on the globe. effengud software sells a high-speed COM component and the complete US Zip code database for as little as $99. Click here for more details.

The DegToRads function is mainly used in support of the GetDistance routine, but can be used by itself. It simply converts decimal degrees to radians.

The DecimalDegToDMS routine can be used to convert decimal degrees (e.g. 32.9697) to a more readable degrees/minutes/seconds (e.g. 32° 58′ 10″).

So, using our example above, how would we go about creating a store finder application? It’s actually pretty straightforward. You could ask a visitor to your website to give you their zip code. You would then look up their zip code in your handy-dandy zip code database (mentioned above). This would yield their latitude and longitude. You would then cycle through your database of store locations, calculating the distance from the user to every store, sorting them by distance. When finished, present the user with the three stores that are closest to them.

NOTE: This article has a follow-up article that explains how to greatly reduce the search time required for a dealer locater application. To read it, click here.

Adding geographical calculations to you website can provide users with interesting and useful information. I hope this article has helped give you the headstart you need to implement such features. Feel free to >contact me with any enhancements you make to this software!

Article collateral materials:

    View/download the script in text format