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
_______________________________________________
talk mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk
