[OSM-talk-be] bug adresse

[Marc Gemis]

Nominatim never takes any data from the node, besides the housenumber.
With the addr:street of the node it find the closest street with the
same "name". It can also use an associatedStreet relation to find the
street.

Then everything else is taken from the street. If the street (or any
other item) belongs to 2 admin levels (or postal codes), Nominatim
takes "the first". There is no way one can influence "the first".


I guess the changes in the code will be too involving to be fixed.
There are other geocoders (e.g. Pelias or in OsmAnd). maybe they
resolve this situation better.

regards

m.


p.s. with this Overpass query http://overpass-turbo.eu/s/rh3 one can
see that the postal coe boundary does not follow the road (at this
moment).

On Sat, Aug 26, 2017 at 6:47 PM, marc marc <marc_marc_irc at hotmail.com> wrote:
> Thank you, I did not know the Nominatim report,
> it is very useful.
>
> Would it be interesting to ask that Nominatim use
> associatedStreet or "is_in boundary" belonging
> to the node or building instead of using
> the "is_in boundary" of the street ?
> Because there are many streets that are a boundary
> between two municipalities.
> It would be strange to duplicate is_in tag on many
> nodes/buildings that are already in the right boundary
>
>  > split the street exactly on the boundary.
> Split ? or merge ? Because imho, the communal limit
> is the middle of the street.
> The difference between street and boundary seems
> to be a precision error or "tag for rendering"
> Way 28825406 should use nearly all nodes as way 237824921
> the only not-shared node could be at "avenue de la liberté"
>
> Regards,
> Marc
>
> Le 26. 08. 17 à 17:54, Yves bxl-forever a écrit :
>> Hello,
>>
>> This is a really interesting problem, and it looks like a documented weakness of the algorithm.
>>
>> This is what the Wiki says about this (https://wiki.openstreetmap.org/wiki/Nominatim/FAQ#How_was_the_address_calculated.3F)
>>       Features down to street level addresses are calculated using a combination
>>       of admin boundaries, is_in tags and place features.  For building level features
>>       addresses are calculated using the address of the most suitable street.
>>       If no explicit boundaries or relations are included the system will fall back
>>       to a simple 'nearest' calculation—this will often be wrong!
>>
>> This is how Nominatim computes the address for that house.
>> https://nominatim.openstreetmap.org/details.php?place_id=26946130
>>
>> In this case, it appears that the street is found within 2 municipalities.  Node 66192903 (Koekelberg) is closer than node 66196464 (Molenbeek) → it assumes the house is located in Koekelberg.
>> If we want to solve this, either we should fill "is_in" keys everywhere or split the street exactly on the boundary.
>>
>> Have a nice day.
>> Yves
>>
>>
>>
>> On Sat, 26 Aug 2017 14:29:18 +0000
>> marc marc <marc_marc_irc at hotmail.com> wrote:
>>
>>> Bonjour,
>>>
>>> Je ne comprend pas où est l'erreur pour l'adresse de ce nœud
>>> http://www.openstreetmap.org/node/2528505484
>>>
>>> Un clic droit "afficher l'adresse" donne "1, Rue de Normandie,
>>> Koekelberg, Bruxelles-Capitale, 1081, Belgique"
>>> L'erreur est 1081 au lieu de 1080.
>>>
>>> La rue a un côté 1080 et l'autre côté 1081 mais je ne trouve
>>> pas où se trouve le 1081 erroné. Le nœud fait partie de :
>>> - is_in Chemin : Stade du Stippelberg (30163631)  pas de postal_code
>>> - Relation : Rue de Normandie (3321170) addr:postcode=1080
>>> - is_in  Relation : Postal code 3379417
>>>    qui a boundary=postal_code + postal_code=1080
>>> - is_in Relation : Molenbeek-Saint-Jean (58255)
>>>    qui a boundary=administrative + addr:postcode=1080
>>>
>>> Il y a quelque chose que je n'ai pas vu ou c'est un bug ?
>>>
>>> Cordialement,
>>> Marc
>>> _______________________________________________
>>> Talk-be mailing list
>>> Talk-be at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>> _______________________________________________
>> Talk-be mailing list
>> Talk-be at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>
> _______________________________________________
> Talk-be mailing list
> Talk-be at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be