> 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
