Le cas des relations ayant les mêmes membres s'est déjà posé, parce que JOSM par exempel les signale comme des doublons, malgré leurs tags différents. Certains ne voient pas cela comme étant juste un "warning" destiné à vérifier qu'il n'y a pas doublon (ce qui cause aussi des problèmes de rendu ou d'analyse dans les applications), et cumulent dans la relation les tags destinés à des fonctions différentes. Dans ce cas, in ne sait plus comment interpréter ces tags
Mais sur les éléments de géométrie de base (ways et noeuds), clairement il faut que les tags dont l'interprétation dépend directement d'un autre tag et pas d'un autre, il faut que ce tag soit clairement associé par son nom à cet autre tag qu'il sert à préciser. Ainsi admin_level a clairement été défini dès le départ pour ajouter une précision à boundary=administrative et certainement pas autre chose comme ce qui a été fait (en France seulement et à l'initiative en fait d'une seule personne qui l'a imposé partout sans réfléchir aux conséquences, notamment car le tag n'avait jamais été concu pour être utilisé à autre chose : les prérequis ne fonctionnaient plus, sur un tag qui était déjà très largement utilisé dans la façon dont il avait été décrit, et cette réutilisation abusive a cassé des applications existantes qui ne se sont pas adaptées car elles étaient basées sur les spécifications existantes). La prochaine fois que vous voulez étendre la signification d'un tag pour autre chose, réfléchissez un peu à la compatibilité. Et il ne suffit pas de compléter la doc sur le wiki, car cela resterea unilatéral alors que le tag est déjà utilisé d'une autre façon par énormément de monde qui n'a pas été consulté. Noter aussi que les relations ne sont pas les seuls moyens de représenter une zone: s'il n'y a pas lieu de découper les frontières parce qu'un élément de même type n'est pas présent à ses frontières, OSM suppose déjà qu'une relation n'est ni nécessaire, ni souhaitable (on ne veut pas de relation à un seul membre par exemple), et on se retrouve donc avec des chemins qui devraient disposer exactement des mêmes tags... Il n'y a pas à faire de dichotomie d'usage des tags entre relations, chemins et noeuds dans OSM, les mêmes tags doivent être utilisables pour les trois avec la même signification, et c'est bien plus important qu'une prétendue unification non nécessaire de tags en apparence identiques mais qui ont des rôles bien différents (le pire tag actuel étant "type=*" qui ne signifie plus rien de valable, devenu impossible à utiliser aujourd'hui et donc devenu clairement redondant et à remplacer partout par des tags spécialisés). Le 9 juin 2013 14:27, Vincent de Château-Thierry <v...@laposte.net> a écrit : > > 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<http://lists.openstreetmap.org/listinfo/talk-fr> >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
