[Geocoding] Questions about Nominatim geocoder

Coulombe, Greg Greg_Coulombe at Intuit.com
Wed Apr 10 17:01:11 UTC 2013


Hello,

I have been experimenting with the Nominatim to handle geocoding freeform addresses and have observed a few issues and I'm wondering if there are workarounds that people might recommend. Here are some of the things I've observed:

  1.  Road exists but address has wrong locality. There seem to be lots of these kinds of cases in which the road exists but it's not in the locality specified in the input and so the geocoder fails. This seems to be a common problem for suburban addresses. Is there a way to enable a search that looks at nearby localities? Examples:
     *   "15083 W. FORD DRIVE, PARK HILL, OK, 74451" ("Cherokee", not "park hill")
     *   "1125 Pond Side Dr, Colorado Springs, CO, 80911" -> Is in "El Paso County", not Colorado Springs
     *   "279 E.G. Fowler, Waycross, GA, 31503" -> Road is actually in neighboring county ("brantley")
     *   "1 Tranquility Base, Huntsville, AL, 35805" -> Road is actually in Madison (which is, in turn, part of the Huntsville metro area)
  2.  Fallback: if the street component of the address is not parseable or not found, can the geocoder be configured to fall back to the next less granular address component (i.e. house number --> street --> city --> province). For example: "Foobar, Madison, AL" should resolve to "Madison, AL". This would be the case for post office boxes as well – the geocoder could just return the city instead of failing altogether for those addresses.
  3.  Zip+4: the search seems to fail for Zip+4 zip codes. Should these be filtered out in the input or is there a way to get the geocoder to ignore them?

Thanks!

--GKC



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/geocoding/attachments/20130410/99abd662/attachment.html>


More information about the Geocoding mailing list