We should stick to the current well known scheme, thinking about this
renderer issue... it makes no sense to manoevre around a faulty
renderer, being it nominatim or a tileserver. If a search for a street
+ housenumber, city returns nothing, but a search for that same street,
city without the number does return fine, who's fault is that? Search
engines are suppose to be 'best effort' . The correct behavior should
be to drop the housenumber from the search parameters (no exact match is
found), and then lower the resolution of the result set to encompass the
street (visually). In nominatim that would translate to bunch of hits
when searching for an address, when reverse searching for a coordinate
that would just return : streetname , postalcode, city, country no
housenumber.
That proposal ,I mentioned that in a earlier comment already, (to be
aware of it's existance) but it's flawed as you noticed. Also, there
are 203 occurences in the whole database like this:
http://taginfo.openstreetmap.org/keys/addr%3A1%3Ahousenumber
Safe to say, it would be a lost effort following this scheme. But also,
we would be the only ones using it imho .... We should just keep
tagging the karlsruhe way.
Glenn
On 2013-10-21 14:40, Marc Gemis wrote:
And I'm not the only one: see
http://wiki.openstreetmap.org/wiki/Talk:Proposed_Features/Multiple_addresses
none of the comments was in favor of this proposal.
On Mon, Oct 21, 2013 at 2:38 PM, Marc Gemis <marc.ge...@gmail.com
<mailto:marc.ge...@gmail.com>> wrote:
2013/10/21 Pierre Parmentier <pierrecparment...@gmail.com
<mailto:pierrecparment...@gmail.com>>
# Proposed Features/Multiple addresses
<http://wiki.openstreetmap.org/wiki/Proposed_Features/Multiple_addresses>
I don't like this proposal too much. This is a relation in
disguise. So why not use a real relation instead ? A building
relation (which already exists) with multiple address node
members. -- I know it's not your proposal, so I won't shoot the
messenger :-)
This is a mess to maintain if you have to manually make sure that
all numbers behind a addr: are there. I would vote against it.
m.
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be