[OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)

[Vincent de Chateau-Thierry]

Bonjour,

Le 25/09/2010 13:27, Benoît ROUSSEAU a écrit :
>
> Pour les subarea je n'est remarqué aucun consensus, Pierre Quenee nous a
> proposé, comme base de travail, l'adaptation sur un modèle existant et
> Émilie à évoqué subarea en nous disant "ca ne me plait pas mais ça
> existe par ailleurs".
Oui, tout à fait. Mais hier soir je disais : "_si_ il y a consensus".

> Mis a part le modèle proposer qui reste à affiner, renommer les tags, le
> compléter, il n'y a pas incohérence avec le modèle actuel bien au
> contraire c'est un complément indispensable ! C'est le modèle actuel qui
> nous amène à l'incohérence. Soit en hiérarchisant de haut en bas : des
> éléments qui pour certains ne sont pas des limites administratives ou
> des élément qui devraient être au même niveau administratif sur des
> niveaux différents. Même si nous rajoutions une numérotation de niveau a
> plus de 10 échelons, ce serait faux ! Ce n'est pas parce que le modèle
> qui fait consensus dans la base est limité que nous devons le reproduire
> bêtement à l'infini en entrant des données dedans au chausse pied en
> considérant que c'est un fourre tout. Tagguer un admin level 7 pour une
> communauté de commune est une erreur si les communes sont en 8 ! Ou
> alors il faut compléter le modèle actuel en ajoutant des compléments
> d'information pour distinguer les limites administratives placées au
> même niveau.

Je viens de relire ce que je disais hier, et ça prête à confusion, je 
comprends ta réponse. Je ne parlais (ne voulais parler) que de la 
manière de construire l'objet com'com : par une relation de type 
boundary=*, ou par une autre de type region=*. Il est clair pour moi que 
dans un cas comme dans l'autre, le tag admin_level=* n'a rien à faire 
dans cette relation. En revanche, il est présent dans chacun des membres 
de la relation.
En essayant de reformuler : "quand on agrège des communes pour 
construire un département, on utilise boundary=*, pourquoi ne pas 
utiliser aussi boundary="autre chose" pour agréger des communes à 
l'échelle d'une com'com."

> La solution de la relation est très pratique et flexible puisqu'elle
> évite d'avoir nécessairement à ressaisir les contours en incluant les
> contours des communes. L'argument comment on fait s'il n'y à pas de
> contours de communes ne tient pas, il faut les tracer.
Facile à dire, et j'aimerais être d'accord avec ça, mais il faut être 
lucide, la courbe de croissance des limites admin est plutôt faible. 
Construire une version temporaire de com'com, avec les nodes place=* 
permet déjà d'identifier la com'com et ses communes constituantes (via 
leur ref:INSEE) ainsi que, au mieux, ses domaines de compétence. Le jour 
où les contours de commune existent, on remplace le node place=* par la 
relation boundary=administrative, mais au moins comme ça on ne créé pas 
d'adhérence entre les objets com'com et limite admin. Utiliser le node 
place=* est une suggestion pour gérer une situation transitoire, pas ce 
qui devrait être le modèle définitif.

  Personne ne se
> pose la question de tracer une route sans ways ou d'indiquer des sorties
> d'autoroutes sans l'autoroute. Qui plus est la relation permet d'ajouter
> un contour propre à la com'com.
> Le plus important même si l'on tâtonne en base est d'avoir l'ensemble
> des informations cohérentes pour transtyper automatiquement ces éléments
> si nécessaire dans le futur. Ca la relation et le modèle proposé le
> permettent.

Tout à fait. Et cela peut valoir aussi bien pour membres de la relation 
(de node place=* à boundary=administrative) que pour les tags. A mon 
avis :-)

vincent