Dans l'immédiat j'en ai eu grand besoin pour reconstruire des tonnes de frontières brisées. En attendant ces name minimums (pas les left/right) facilitent le travail pas que dans l'éditeur, mais aussi dans tous les autres outils (Osmose, historique OSM standard...). On voit plus facilement ce qui a été touché et où.
Concernant les left/right je ne vois aucun inconvénient à les enlever, ils sont souvent faux d'ailleurs car les gens ne connaissent pas leur droite et leur gauche (ils interprêtent en fonction de ce qu'ils voient à l'écran et non en fonction du sens de parcours du chemin). Les name ont également un autre avantage : ils facilitent les sélections dans les listes de membres de relations (particulièrement les grosses relations). Je ne vois pas comment un éditeur pourra améliorer cela puisque cela les obligeraient à télécharger sans arret la liste des relations dépendantes. Les name=* ont toujours été des outils pour l'édition. Ils ne sont sensés s'afficher sur une carte que pour quelques éléments ponctuels ou linéaires totalement autonomes. Je ne les ai pas du tout mis pour le rendu (puisque Mapnik de toute façon affiche tous les name du way et de toutes les relations dépendantes, sans réel discernement, mais Mapnik dans sa version déployée pour le site OSM n'est pas vrai rendu cartographique, c'est un rendu "technique" orienté éditeur, mais pourtant très imparfait de ce point de vue-là). Imagine que JOSM sache afficher ces names ? combien va-t-il en afficher ? Comment jugera-t-il ceux qui sont les plus pertinents à afficher pour aider le contributeur ? Jusqu'à présent il affiche le name propre à chaque objet et c'est tout (des plugins affichent des "[8]" et le type d'objet mais jamais un nom utilisable) Savoir choisir un libellé pertinent n'est pas une chose facile, c'est même ce qui fait tout l'intérêt de la conception du rendu d'une carte que de savoir choisir quoi afficher et où (alors que la base OSM contient tout) en fonction de divers critères de ce que la carte veut montrer et de son échelle. Mais dans un éditeur où tous les noms auraient la même importance, on doit faire quelques choix. Par principe j'ai choisi de nommer un objet uniquement en fonction de ce qu'il désigne et de son niveau administratif : même si cela sépare deux communes, si cela sépare deux régions, ce sont les noms des deux régions (la valeur admin_level la plus faible parmi les relations qui utilisent ce way de frontière) : cela privilégie largement les relations les plus grandes, mais c'est finalement ce qui est le plus pratique à voir. Le 6 octobre 2012 17:05, Vincent de Chateau-Thierry <v...@laposte.net> a écrit : > > Le 06/10/2012 16:00, Philippe Verdy a écrit : > >> Les left: et right: sont effectivement une plaie inutile. >> En revanche les name ne sont pas là pour le rendu mais pour s'y >> retrouver dans une longue liste d'objets où n'apparaissent que des >> IDs, afin de savoir ce que ça touche lors de l'édition. >> >> Un name unique suffit. Il y en a partout, ils ne sont pas faits du >> tout pour le rendu concernant les limites administratives. > > > @Philippe : dans nos échanges par MP sur ce sujet il y a plus d'un an, tu > invoquais le rendu comme motivation pour nommer les frontières admin d'IDF. > > > Très utile >> >> pour regarder les historiques, ou s'assurer qu'on sélectionne l'objet >> attendu dans un éditeur. Cela évite des tas d'erreurs qu'on doit >> corriger péniblement plus tard en chargeant un volume conséquent de >> données sans pouvoir toujours les réidentifier. >> > > D'accord de mon côté sur le principe d'ôter les "name=*" de ces ways. Si la > justification de ces noms est de faciliter le travail dans les éditeurs, > alors faisons évoluer les éditeurs. Côté JOSM l'affichage des appartenances > d'un way à des relations existe depuis longtemps, et c'est, je trouve, la > bonne réponse à ce besoin fonctionnel. > > Si on s'accorde sur la bonne pratique qui consisterait à ne pas nommer les > frontières admin, pas besoin de bot, les suppressions faites par chacun au > fil des éditions devraient rapidement faire maigrir les stats. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
