Il me semble que Nominatim n'utilise plus is_in depuis longtemps (beaucoup trop d'erreurs) mais plutôt les frontières. Sauf en dernier recours quand il ne parvient pas à fermer une frontière ni calculer un centroïde.
Je l'ai déjà vu assez souvent quand la frontière bretonne était cassée : Rennes apparaissait alors en Loire-Atlantique dans Nominatim, malgré ses tags is_in qui sont là depuis longtemps, car Nominatim utilisait visiblement un calcul basé sur la distance entre les centroïdes calculés des régions (Nominatim peut calculer un centroïde même sur des frontières cassées, en utilisant apparemment soit les noeuds des chemins qui restent soit ceux de la bounding box). Cela a pu changer encore étant donné la fragilité aussi de l'heuristique des centroïdes. Mais dans tous les pays sauf la France où ils ne sont pas utilisés, Nominatim ne se trompe jamais avec les membres de rôle subarea, qui sont très stables et très peu fragiles. Le 11 octobre 2012 14:26, Vincent de Chateau-Thierry <v...@laposte.net> a écrit : > >> De : "Pieren" > >> 2012/10/10 Vincent de Chateau-Thierry : >> >> > Si c'est juste pour fixer l'organisation administrative et organiser des >> > relations d'inclusions sans géométrie, personnellement je pencherais plus >> > pour des relations imbriquées que pour le recours au tag is_in et à ses >> > déclinaisons, pour plusieurs raisons : >> >> Bon, je vais donner ma liste des contre-arguments: >> - les relations, ça se casse aussi (vs fiabilité des "is_in"). Ca >> arrive presque tous les jours sur les boundaries français. Bon, c'est >> vrai que les noeuds "place" sont moins souvent manipulés que les >> frontières. Mais c'est la même chose avec les places dans "is_in" qui >> sont rarement modifiés. >> - le schema "is_in" est l'ancien schéma qui existait avant la création >> des "boundaries". C'est aussi pour ça qu'il est déjà supporté par des >> outils comme Nominatim contrairement à toute nouvelle relation qui, >> dans le meilleur des cas, ne sera pas supporté avant des mois (2 ans >> pour que nominatim tienne compte de admin_centre) ou dans le pire des >> cas, ne soit jamais pris en compte par aucun outil (le plus probable). >> - de toute façon, les limites administratives seront tôt ou tard >> ajoutées. La solution à mettre en place ne sera donc que temporaire. >> Difficile de mobiliser les gens sur quelque chose qui va disparaitre. >> > > Au tout début de ma proposition, il y a une question pour Eric : > "Je ne sais pas si tu as un usage en tête pour ce que tu vas modéliser ?" > De sa réponse dépend pas mal le choix à faire, à mon avis. > Si le but premier est de s'inscrire dans les outils existants (principalement > Nominatim) alors oui, bien sûr, l'exercice doit consister à entrer dans un > moule connu de Nominatim. Si le mode "is_in" est reconnu, alors pas de > question > à se poser, il faut l'utiliser. > Dans ce que je proposais hier, je m'affranchissais de ce besoin (parler la > langue > de Nominatim ou d'une autre appli bien établie), je cherchais plutôt la > modélisation > qui me paraît la plus pratique pour organiser une organisation arborescente et > la manipuler, mais en faisant l'hypothèse qu'Eric a la maîtrise des outils > qui la > manipuleront. Typiquement : il charge ces données dans une base relationnelle > et > a besoin de connaître des relations entre entités administratives. Dans ce > cas, les > propriétés d'inclusion dans une relation avec un rôle sont bien plus pratique > pour > lier les objets, que la valeur du tag is_in. > D'accord sur un point, comme tu le rappelles : tout ceci est un exercice > temporaire, > la cible étant de pouvoir embrayer sur une modélisation type boundary lorsque > les > données (géométriques) seront disponibles. Et c'est ce côté temporaire qui me > fait > proposer sans trop de scrupules des tags pas forcément établis ni reconnus > (typiquement > le rôle "commune" ou "village"). > > vincent > > Une messagerie gratuite, garantie à vie et des services en plus, ça vous > tente ? > Je crée ma boîte mail www.laposte.net > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
