[FoRK] map search

Stephen Williams sdw at lig.net
Sat Mar 2 13:49:09 PST 2013

It's easy to compute distance between zip codes, and distance between geographic points.  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.

In other words, chunk all addresses into geographic square nodes, then use mapping services to establish routes with nearby 
nodes and identify the long-range paths to the segmented sets of all nodes.

Or, cache actual path lookups as they are requested.

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.


On 3/2/13 8:16 AM, J. Andrew Rogers wrote:
> On Mar 2, 2013, at 7:32 AM, Kelley Howell <kcwalker at inkworkswell.com> wrote:
>> Sorry. I forget my audience sometimes. :) Map as in "I want to book a hotel in Raleigh, NC that's close to my client's site."
> What kinds of data types, data sets (type and size), update rates, and queries (type and rate) are involved? Unless the total data set size being searched is small, design choices here will bleed into the user experience.
>> I'm working on the interface and user experience.
> Does it cover the whole Earth or is it geographically constrained?
> There are best practices, but many of them are conditional on the nature and scope of the app.
> Andrew

More information about the FoRK mailing list