Le 09/06/2013 13:08, Philippe Verdy a écrit :
Le 8 juin 2013 16:05, Vincent de Château-Thierry <v...@laposte.net
<mailto:v...@laposte.net>> a écrit :
Et en toute logique, il faudrait si on l'applique, le propager aussi
aux boundary=administrative, à la place d'admin_level.
Certainement pas (ou à la limite seulement dans les relations
administratives (et qui ne sont QUE administratives et ne servent pas
aussi de limites pour autre chose).
Je veux bien un exemple d'une relation admin qui sert à autre chose.
S'il y a réellement 2 notions, alors on fait 2 relations, quitte à ce
qu'elles aient les mêmes membres.
L'ennui c'est pour les ways (fermés ou non) qui ont des utilisations
multiples. Il se posera alors la question de savoir à quel autre tag
présent sur ce way correspond ce "level" car justement le "level" n'est
PAS orthogonal mais lié à un seul autre tag.
Ma proposition de généraliser boundary:level était surtout pour les
relations, mais je ne l'ai pas précisé. Tu as raison de souligner la
question des ways. Dans le cas des ways, il y aurait plusieurs possibilités.
Je vois au moins :
- garder le couple boundary=administrative+boundary:level=<valeur
actuelle d'admin_level> (status quo, manière de reconnaître
l'antériorité des limites admins dans de nombreux cas, les autres
limites étant dérivées de celles-ci),
- migrer vers le couple boundary=administrative+boundary:level=<valeur
actuelle d'admin_level>
=> homogénéiser les tags entre ways et relations
- aller au bout de la logique de boundary:level, et donc enlever des
ways ce tag, vu qu'il peut, selon le type de limite décrite, avoir
plusieurs valeurs pour le même way. Les ways seraient juste taggués
type=boundary, sans référence à un niveau ni à un type de limite, ces 2
infos étant portées par chaque relation qui référence le way,
- affecter boundary:level avec la plus petite valeur de 'level', issue
de toutes les relations qui référencent le way (en gros ce qu'on fait
déjà, juste pour les relations administratives)
Bref, pas simple, et à discuter. Je penche personnellement pour la 3e
proposition (enlever les tags). Mais c'est un peu radical vis-à-vis de
l'existant...
À court terme, ça me semble plus directement applicable aux relations
elles-mêmes, quitte à faire cohabiter dans un premier temps pour des
questions de compatibilité les tags admin_level et boundary:level.
Franchement je ne comprend pas l'utilité même de vouloir unifier des
tags sous un même nom alors qu'ils ont des significations complètement
diférentes et ne sont pas liés aux mêmes données (et clairement pas
orthogonaux comme peuvent l'être "name", "url", "wikipedia", "natural",
"landuse" et "boundary").
La signification n'est pas la même, mai le concept, oui : on parle
d'organisations hiérarchiques, où la notion de niveau (level) a tout son
sens.
vincent
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
