How to represent street address ranges for geo location lookups?

Question

I have the following type of inputs:

Zone 1 =>
  Alabama street, 1 to 135, west side
  Alabama street, 2 to 144, east side
  Bahama square, 2 to 4
Zone 2 =>
  Bahama square, 5 to 8
  Cecil street, 3 to 27

etc.

These data represent certain zones within an area. Like a small disctrict in a city, defined by a couple of enclosing streets.

If I'm given a geo location (latitude, longitude), how can I map this value to a zone in the above context? It's obvious that a google maps lookup will give me the address, but how to proceed from there? What is the best way to represent this kind of data (address ranges) for effective zone establishment?

(whoa, 3 questions within 1)

Answer 1

I'll take a stab at the followup question. I am assuming streets 1 .. 6 in Zone 1 are major streets and Zeta is a side street between these streets within the address range.

My solution would be to form a shapefile for the zone and then check if the lat/lng of the address to check is within the shapefile. Here's some approach detail:

1. Use the reverse API to get the lat/lng of each street endpoint (e.g., 1 w. alabama, 135 w. alabama, etc).

2. Use these endpoints to create a polygon shape (shapefile) around your zone.

3. Use the reverse API to get the lat/lng of the address to check.

4. Check if this lat/lng is within the polygon shape.

If you decide though to use matching by address, here's a link to the US Postal standard for addresses. You can use this standard for normalizing your addresses.

http://pe.usps.gov/text/pub28/welcome.htm

Andrew The Team at OpenGeoCode.Org

Answer 2

Assuming you will rely on an external source (like Google or Yahoo PlaceFinder) for reverse geocoding, you will get back a street number and a street (let's assume that the city, state, etc all match). Once you have the street and street number, it's matter of querying your "database" of zones.

Thus, what you really want here is an index to help you identify the correct zone(s). You could choose to have an index on street numbers, street names, or the combination of both of them. Assuming you use a constant source like Yahoo PlaceFinder, for example, it would be safe to assume that the output you get will be normalized and it might be feasible to use a (street number, street) index.

However, it would probably be more robust (i.e., less error prone due to name+number variations) to create an index on a normalized form of the street name. As you query the index, you would interrogate each street node to see if the number you have falls in the range.

So, for example, your index could look like this:

w. alabama ==> 1 <to> 135 ==> zone 1
e. alabama ==> 2 <to> 144 ==> zone 1
    bahama ==> 2 <to> 4 ==> zone 1
           ==> 5 <to> 8 ==> zone 2
etc.

The above shows that I've normalized the street addresses (case plus accounting for things like "west" vs "east") in a way that is in sync with my external reverse geocoder. I then implement a range lookup in the second level of the index (which is why I wrote , implying that you would need to implement that logic), so that I don't have to enumerate all of the numbers between. NOTE: A lot of the details for format/representation here will depend on the customs obeyed by your reverse geocoding source, so it's important you consider the canonical/normalized form of this data or else you will get many false negatives.

You could, of course, do much of this with the assistance of a relational DB, depending on their support for range indexes. But if you don't have one handy or would prefer not to integrate with one, I think the above custom index would work.