http://www.spikesolutions.net/ViewSolution.aspx?ID=1e7d197c-7441-40f4-8e87-5ecc3ef5ab60

I think TIGER lat/lng zip code data is nice but not very useful for applications that require comparisons of distances for actual locations (i.e. stores, homes, movie theaters, etc.) from a given starting lat/lng. Most people might want to find distances from their home to the nearest drug store or even to list all drug stores within a given radius. From a development perspective, this is problematic because given a single starting point, there can be any number of target points within a certain search result set. Now throw in the variable that the start point maybe chosen at random by the user and you could be left with a very high number of point-to-point comparisons for distance. Doing these calculations on the fly is rather expensive and depending on the scale of your deployed application, even caching (MySQL or higher) can prove rather useless given the variability of start and end points.

The ability to find a result set given a radius can be especially difficult given large data sets. It is impractical to compare the distance from every point to every other point, even if your starting lat/lng remains constant. What I have worked with and maintained in the past is the creation of a bounding box to gather all points within a given radius. It is relatively inexpensive to calculate the top, bottom, left, and right lat/lng values of given start point and to query only the points that fit within that “box” then calculate the distance of each. On a small scale(.5-10 mile radius), this works pretty well, but as you start to increase this distance, your result set begins to get less accurate due to the inclusion of points beyond your desired radius. The distance from the center to the top, bottom, left, and right points of the “box” remain accurate but as the radius distance increases the corners of the “box” extend further and further beyond the desired radius.

For all of the radius searches, you’re looking at about 78% area accuracy (22% falls outside of the circle and into the square areas of the bounding box). But the accuracy falls a lot more when you work with the linear distances from the center of your radius. The distance from center, along the diagonals of the search box to one of the corners (the furthest possible point), the numbers start looking like…

radius(in miles) | dist to box corner
0.25 | ~0.35 => 0.10 miles extra
0.50 | ~0.71 => 0.21 miles extra
0.75 | ~1.06 => 0.31 miles extra
1.00 | ~1.41 => 0.41 miles extra
1.25 | ~1.76 => 0.49 miles extra
1.50 | ~2.12 => 0.62 miles extra
1.75 | ~2.47 => 0.72 miles extra
2.00 | ~2.83 => 0.82 miles extra
2.50 | ~3.54 => 1.04 miles extra

The numbers show that the searchable radius can be, at its absolute worst, 40% off for all radius distances. Maybe this level of error is acceptable but probably not for most of us.

This does not even include the apsect of mapping. Getting lat/lng data and distances from points of interest is good but are usually only useful when mapped for the user. Unfortunately, lat/lng data does not always correlate well with all map rendering applications. For instance, Google maps uses different map data vendors like Europa and Tele Atlas depending on if you are using their maps.google.com application or the development API. I can tell you from experience that the same lat/lng can and often DOES map differently on each.

So in sum…just pay for it ;)