[OSM-dev-fr] Question bdd Nominatim

[Philippe Verdy]

Exemple des problèmes liés à la fermeture instable des frontières de
la Bretagne :

http://tools.geofabrik.de/osmi/?view=multipolygon&lon=-3.53825&lat=48.38877&zoom=9&overlays=ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags

Cette frontière est tellement longue (et difficiel à charger en
totalité) qu'elle est souvent modifiée localement, mais pas toujours
retriée ni maintenue connexe. Le calcul des enveloppes convexes fait
apparaiître alors des discontinuités qui plantent les algos utilisant
les enveloppes convexes et centroïdes comme moyen de repli
heuristique.

Pour éviter le problème, il est donc important de toujours retrier les
trontières dans le bon ordre (dans le sens antihoraire), si on modifie
un peu celle-ci (cela permet aussi de constater aussitôt les "trous"
dans les frontières, oubliés par certains modificateurs qui ne
chargent pas toutes les relations auxquelles appartiennent les
frontières modifiées).

Ceux qui touchent à la frontière maritime doivent faire attention:
s'il coupent un chemin en deux, ils doivent absolument s'assurer de
charger la zone autour du point de découpe pour être certain d'avoir
chargé aussi toutes les relations utilisant la frontière passant par
ce point:

Il n'est pas nécessaire de charger toute la Bretagne (c'est lourd et
généralement ça ne passe pas, le serveur rejette la requête trop
volumineuse), mais il suffit juste de zoomer au maximum autour du
point de découpe qu'on veut ajouter sur la frontière maritime, pour
juste charger une microzone autour de ce point. On obtient alors la
liste intégrale des relations utilisant ce point, et TOUTES ces
relations sont à maintenir en même temps pour éviter de les casser.

Le 3 avril 2012 06:07, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
> Ce problème de Nominatim n'est pas nouveau et a déjà été discuté. Il
> ne tient pas compte des admin_center indiqué pour trouver la région
> d'appartenance et utilise un algo compliqué qui se plante a un moment
> car il utilise un centroïde calculé sur les régions et trouve que
> Rennes est plus proche géographiquement du centroïde calculé des Pays
> de la Loire que de celui de la Bretagne (de peu, quelques kilomètres,
> mais ça suffit...)
> Nominatim ne cherche pas à savoir si le point Rennes est bien dans les
> frontières de la région, ou bien a un problème pour déterminer la
> frontière **fermée** de la Bretagne et ne peut pas faire ce test, mais
> s'en remet alors aux centroïdes calculés.
>
> Ce problème peut survenir survient chaque fois qu'une région
> environnante a une assez forte concavité (c'est le cas des Pays de la
> Loire : si tu traces une ligne droite entre ses points de frontière le
> plus au nord-ouest, ce trait va traverser une partie significative de
> la Bretagne. Le centroïde calculé des Pays de la Loire est
> significativement déplacé vers la Bretagne, laquelle est pourtant
> assez bien convexe pour que son enveloppe convexe n'inclue pas
> d'autres parties signiificatives des région environnantes.
>
> Nominatim donc bien a un bogue, son algo n'en est pas un, c'est une
> heuristique seulement, qui a ses failles. Le problème se retrouve
> d'ailleurs dans d'autres régions du monde dont les frontières
> administratives sont un peu trop concaves ou incluent des enclaves (je
> l'ai vu régulièrement partout en Espagne par exemple, qui compte de
> nombreuses régions avec enclaves, en Russie avec des régions en forme
> de croissants), et même dans des comptés en Angleterre et certaines
> régions en Allemagne (j'ai déjà vu Berlin changer plusieurs fois de
> région...). L'algo utilisé est instable et se perd au moindre petit
> changement local d'une frontière, même si les admin_center sont bien
> indiqués.
>
> Le 2 avril 2012 11:16, Charles DESNEUF <cdesneuf at capptain.com> a écrit :
>> Suite des aventures :
>> J'ai tenté la solution que je proposais en passant par Osmosis pour ne
>> garder que les infos interessantes pour mon cas en me basant sur la liste
>> des map features ( dispo ici
>> : http://wiki.openstreetmap.org/wiki/Map_Features ).
>> Après avoir mis de côté les nodes et ways contenant tags boundary,
>> border_type et place avec l'option --tag-filter j'ai lancé un import. Jusque
>> là pas de souci.
>> Rapide test ce matin sur les données importées, et là horreur(relative,
>> petite guerre entre voisins) Rennes se retrouve en Pays de Loire, alors que
>> la Bretagne est bien indiquée lorsque l'on s'en va d'avantage vers l'ouest.
>> J'ai 2 et demi pistes pour le moment :
>> - Nominatim a besoin de se baser le plus bas possible pour être sûr de pas
>> se planter (le reverse geocoding sur les serveurs OSM indique bien Rennes en
>> Bretagne).
>> - J'ai sur-trié et enlevé des tags que je n'aurai pas dû, même si j'ai
>> l'impression d'avoir fait un trie à la va-vite en gardant des infos
>> "sans intérêts".
>> (- J'ai récupéré une vieille version d'un fichier planet, mais les miroirs
>> ayant l'air à jour pour cette semaine je ne pense pas avoir réussi à tomber
>> sur le seul miroir qui n'était plus maj depuis 2 mois et l'a été dans le
>> week-end...)
>>
>> Personne par ici n'a été confronté à ce genre de pépin ?
>>
>> 2012/3/27 Charles Desneuf <cdesneuf at ubikod.com>
>>>
>>> C'est pour le monde.
>>>
>>> Le 27/03/2012 12:21, Christian Quest a écrit :
>>>
>>>> C'est pour quelle couverture ? France, monde ?
>>>>
>>>> Si tu ne fais que  du geocoging sur la France au niveau ville, utilise
>>>> GEOFLA !
>>>>
>>>>
>>>> Le 27 mars 2012 12:08, Charles Desneuf<cdesneuf at ubikod.com>  a écrit :
>>>>>
>>>>> Bonjour à tous,
>>>>>
>>>>> Je suis en train d'étudier la possibilité de passer sur des données OSM
>>>>> afin
>>>>> de gérer du reverse geocoding et se pose du coups quelques questions :
>>>>> Savez-vous où je peux trouver des infos sur la place occupée par la BDD
>>>>> de
>>>>> Nominatim actuellement(600GB en janvier d'après la doc d'install) ?
>>>>>
>>>>> Et trois autres questions liées :
>>>>> Je n'ai apriori pour le moment pas besoin d'être plus précis que la
>>>>> ville
>>>>> lors d'un reverse geocoding.
>>>>> Pour limiter la taille de la base est-ce que je peux n'importer que les
>>>>> tags
>>>>> intéressants(ne pas importer les noms de rues, commerces,...) jusqu'à ce
>>>>> niveau là sans que ça pause de problème ?
>>>>>
>>>>> Si oui, l'unique solution que je vois pour le moment c'est de passer par
>>>>> osmosis avec le filtre sur les nodes et ways, de générer un fichier osm
>>>>> et
>>>>> enfin de le traiter avec osm2pgsql. J'ai bon ou il y existe mieux ?
>>>>> Ce qui amène la troisième question : Si dans le futur j'ai, finalement,
>>>>> besoin d'être plus précis, je suis bon pour une nouvelle install d'un
>>>>> fichier planet ?(a moins de refaire la combine avec osmosis, ce qui me
>>>>> parait plus ou moins délicat...)
>>>>>
>>>>> Merci d'avance pour vos avis/conseils =)
>>>>>
>>>>> Charles
>>>>>
>>>>> _______________________________________________
>>>>> dev-fr mailing list
>>>>> dev-fr at openstreetmap.org
>>>>> http://lists.openstreetmap.org/listinfo/dev-fr
>>>>
>>>>
>>>>
>>
>>
>> _______________________________________________
>> dev-fr mailing list
>> dev-fr at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/dev-fr
>>