[FoRK] map search

J. Andrew Rogers andrew at jarbox.org
Sat Mar 2 14:34:59 PST 2013

On Mar 2, 2013, at 1:49 PM, Stephen Williams <sdw at lig.net> wrote:
> It's easy to compute distance between zip codes, and distance between geographic points.

Computing reasonable approximations of distance between geographic points can be difficult; it depends on the assumed path between those points. Still, even geodetic paths are relatively easy and built-in to many environments. 

The distance between ZIP codes is a bit more difficult to compute correctly since a ZIP code is a polygon. Even assuming a simple surface, most people introduce large errors when trying to compute this. There is no open source geometry library that I am aware of that does these computations correctly.

>  Although apparently complex to handle all real-world data and cases, facilities to generate point to point distance are available.  What you need is a cached database with a certain useful resolution of a few blocks that maps distances to addresses.  This can probably be done in a chunky way to keep the mesh density and overall size of the data down.

A caveat is that multi-level grids only work if the data set is approximately read-only. Obviously for things like map data this works great, for representing more real-time data sources, perhaps mixed in with static data, it has limitations.

> Traditionally, zip code distance, since it is easily available with public data, was used for this kind of thing maybe augmented with geographic/crow distance.  Actual driving distance is more difficult to have available for all possible options.  So far.  Especially difficult to make fully informed computations with traffic, time of day intended, construction, accidents, etc.  But possible and something we will have soon.

Ellipses are commonly used to approximate driving areas and driving paths between two points when high precision does not matter. 


More information about the FoRK mailing list