JOSM ne sait pas voir qu'une relation a des tags différents. Il croit que ces relations pourraient n'en faire qu'une alors qu'il y a des tags en conflit, en supposant qu'on puisse fusionner ces tags en un seul avec les valeurs dans un ordre quelconque mais séparées par des points-virgules. Pourtant si c'est possible quand il y a un seul tel tag, il y a aussi d'autres tags uniques spécifiques pour une valeur précise du tag en conflit mais pas un autre. La fusion n'est donc pas toujours possible. En revanche JOSM a raison de râler si entre ces relations tous les tags (hormi les tags à ignorer comme source=* ou les tags rendus invisibles par défaut comme created_by=* qui doivent migrer maintenant en tags non plus sur les objets mais sur les changesets) sont identiques car c'est alors un doublon. Je trouve dommage que JOSM au moins ne fasse pas cette vérification pour savoir si c'est un vrai doublon pour modifier la sévérité du texte de l'avertissement. Comme il ne sait pas faire, en attendant il ne déclare pas que ce sont des erreurs, mais juste des avertissements: c'est à l'utilisateur de voir si c'est un vrai doublon ou pas et de décider s'il doit fusionner ou pas.
Mais si on prend l'exemple d'une relation route qui est indifféremment pour piétons, cyclistes ou chevaux, je ne vois pas bien ce qui empêche de fusionner les relations avec un tag énumérant les valeurs possibles entre point-virgule. L'autre solution ce serait de taguer "foot", "bicycle" et "horse" non pas en valeur d'un attribut mais dans un nom d'attribut (comme on le fait pour "access=foot;bicycle" transformé en "access:foot=yes"+"access:bicycle=yes" Cela reviendrait alors à ne plus utiliser "type=route" + route=foot" dans une relation, et "type=route" + route=bicyle" dans une autre; mais d'utiliser "type="route" dans une seule relation avec deux tags "route:foot=yes" + "route:bicycle=yes" (et non pas un seul "route=foot;bicyle"). On a des exemples similaires avec "shop=*". On a pourtant le cas ou la défusion du tag à valeurs multiples en deux tags séparés (tout en gardant une relation unique) n'a pas été fait: "landuse=commercial;industrial" qui pourait aussi devenir "landuse:commercial=yes"+"landuse:industrial=yes". On n'est pas toujours très cohérent dans OSM... Le 3 mai 2016 à 20:21, Jo <winfi...@gmail.com> a écrit : > Ça choquera JOSM aussi. Le validateur viendra dire qu'il y 3 relations > avec les mêmes membres. > Néanmoins, pour moi, ça me semble la bonne solution. Il y a des doublons > dans les itinéraires des bus pour lesquelles je dois créer de telles > relations qui ne diffèrent que par leur tags. > > Polyglot > > 2016-05-03 19:05 GMT+02:00 Stéphane Péneau <stephane.pen...@wanadoo.fr>: > >> Heu... il n'y a que moi que ça choque ? >> Quelle est la logique derrière ça ? >> Ce ne serait pas plutôt à waymarkedtrails.org >> <http://hiking.waymarkedtrails.org> de gérer ce genre de cas ? >> >> Stf >> >> >> Le 03/05/2016 à 18:45, adrien a écrit : >> >> OK merci pour la réponse, y-a-plus-qu'à ! >> >> Adrien >> >> Le 02/05/2016 18:08, David Crochet a écrit : >> >> Bonjour >> >> Le 02/05/2016 17:39, adrien a écrit : >> >> faut-il que j'ajoute une relation par type de >> déplacement, sachant que c'est le même circuit ? >> >> oui >> >> Cordialement >> >> >> _______________________________________________ >> Talk-fr mailing >> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr >> >> >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> >> > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
