[OSM-talk] Nominatim & US places

[Richard Welty]

On 1/1/11 7:54 PM, Brian Quinion wrote:
>> it's not really leading anywhere, in part due to the fact that
>> noone from Nominatim has spoken up. i did just review the
> Hi.  Yes, I've been off doing new year type things.  I'm playing
> catchup on my email now - and I've still got a hangover so please
> accept my apologies if anything is incoherent.
>
> First of all I'm already working on a lot of this - I'm aware of the
> US address problems and working on improving the code and adding extra
> data (i.e. tiger) to improve the quality so it may just be sensible to
> ignore the whole problem for a couple of weeks and see what happens.
>
which would be fine with me. i just wanted to find out what, if anything,
mappers could do now to help.
>> Nominatim stuff i found in the wiki. they want postal code
>> polygons in the database; in the US this is the extremely iffy
>> zip code boundary stuff that probably shouldn't go in. i think
>> there are some architectural issues to be resolved, but this is
> If postcode polygons don't work use 'addr:postcode' on roads or
> buildings/properties.  There are also special tiger:zip tags from the
> initial import which I've recently added support for which should go
> live shortly.
>
the problem with postcode polygons is that while often they exist,
the US postal service doesn't guarantee direct mapping to understandable
polygons, in fact actively advises against it.
>> but i did find a workaround. i added
>> is_in=Averill Park, NY, US
> The post towns idea in the US isn't one that nominatim currently
> supports and it would probably be better to work out a correct way of
> tagging this rather than missusing the existing tags.
>
based on Anthony's suggestion, i tried addr:city on a way and it's fine.
as for is_in, i've ignored it for a while due to the fact that everyone
seemed a little iffy on using it (and the language of the wiki page
certainly suggests it's iffy). i just tried it as a quick-and-dirty 
experiment,

>> what i still don't get is how it figures out the correct zip code of 12018
>> for the displayed result string, i guess there's some research to be
>> done yet.
> I've back ported some code from the new version a couple of weeks back
> which tries to improve postcode handling for addresses but this is
> just the first stage.  Really I think the zip code stuff is pretty
> much a solved problem (or will be shortly)  the post town issues are
> probably more significant.
from a postal code -> post office mapping issue, in general a postal
code only maps to one post office, so a table showing 12204, 12205,
12206, 12207 and so forth mapping to Albany, NY is an entirely reasonable
thing to do.

richard