Pour les frontières (administratives) ou de contours "inner"/"outer" de polygones surfaciques) la visualisation des chemins marche bien car ces contours n'ont pas réellement d'orientation significative :
- En fait si ! Mais uniquement pour les lignes de côtes maritimes, qui imposent de placer la mer du côté droit, à cause de la façon dont les outils pour Mapnik fonctionnent actuellement : - mais on n'a pas à gérer autre chose dans ce cas que des contours formant des anneaux simples, sans multiples parcours d'un même segment, et fermés non pas dans la même relation mais une série de chemins successifs cherchés de proche en proche mais le plupart du temps jamais réunis dans une même relation qui serait trop lourde à manipuler et que Mapnik n'ira pas chercher de toute façon puisqu'il utilise un fichier précalculé ; - pourtant si le fichier est précalculé, l'orientation des lignes de côtés dans OSM n'a aucun rôle à jouer (le précalcul déterminera cette orientation automatiquement) - l'orientation sera utile seulement si on se passe du fichier pour justement savoir de quel côté est la mer sans avoir besoin de charger et former le contour polygonal complet (par exemple dans un éditeur justement où on ne peut pas tout charger sur des zones très étendues, ce qui est le cas de iD justement) ; - si on indique en revanche l'orientation correcte du côté de la mer, le fichier précalculé ne sert pratiquement à rien pour le rendu, sauf pour économiser des requêtes de chargements aux faibles niveaux de zoom, où il est préférable de disposer d'un tracé très largement simplifié adapté à la faible résolution affichée ; - et pourtant Mapnik utilise encore (inutilement à mon avis) un fichier de lignes de côtes détaillé au maximum, ce qui me semble être une perte de temps pour les niveaux de zoom élevés où l'utilisation directes des chemins venant d'OSM est totalement suffisante (et cela éviterait de garder des contours marins pas à jour pendant des semaines ou des mois sur les rendus) - le précalcul des contours complets simplifiés pourrait pourtant être fait au fur et à mesure des chargements partiels de données, le fichier de côte ne servant alors qu'à l'initialisation d'un chargement complet d'une nouvelle base, mais plus jamais nécessaire ensuite pour les mises à jour. En revanche pour les itinéraires et lignes de transport, la représentation iconique dans JOSM est encore assez "bordélique", pas bien réfléchie, ou au minimum "expérimentale" et jamais finalisé complètement : - les icones fléchées sont mêmes souvent complètement inversées par rapport à la logique, il y a confusion entre "forward" et backward" pour les parties unidirectionelles (et d'autres confusion quand il y a en plus un sens unique, pas toujours dans le sens de numérotation des noeuds du tracé) ; je ne comprends pas du tout la logique utilisée pour ordonner tout ça (et le tri ne marche pas du tout dans ce cas, et échoue aussi quand cela passe par des rond-points larges qui sont découpés en plusieurs segments et ne forment plus un chemin circulaire unique; on se retrouve souvent avec des segments en excédent et un routage qui ne fonctionne pas correctement) ; - même en utilisant des "route_master" pour séparer chaque sens (le "route-master" regroupant une "route" aller et une route "retour", car on a aussi le cas des lignes qui font un décrochage avec demi-tour par le même chemin en sens inverse, un cas encore mal géré, d'autant plus que JOSM n'accepte pas d'insérer deux fois le même membre, même avec des rôles différents; une solution est de découper dans ce cas le sens aller avec deux routes membres dans le sens "forward", en coupant au point de demi-tour, et même chose s'il y en a dans le sens retour; un autre ennui vient alors : dans quel route membre placer les plateformes d'arrêt qui sont au point triple d'un Y dont une des branches est parcourue deux fois en directions opposées pour le même sens aller ? Je pense que le modèle des relations de lignes de transport (y compris la nomenclature nationale ou européenne des itinéraires routiers) est mal adapté à cette représentation "iconique" dans JOSM des membres de relations qui ont une orientation. Et qu'il faudrait un éditeur de relation spécifique pour ordonner les lignes de transport et vérifier les interconnexions. De façon moins grave on a le cas aussi des bras secondaires de cours d'eau : la visualisation ne permet pas de representer toutes les branches secondaires (parallèles en amont, ou en Y à l'estuaire, voir proche de la source pour les sources multiples dont aucune n'est désignée comme "principale"). Pourtant, pouvoir vérifier visuellement les connexions est indispensable. Mais c'est difficile à faire si l'éditeur ne fait que présenter une liste tabulaire : il faudrait des icônes devant afficher parfois plus de 2 chemins parallèles (celui du membre en trait plein, et celui en pointillé pour faire la jonction en sautant les membres non concernés. Cela pourrait se faire en alignant plusieurs icônes côte à côte et rendant la colonne de largeur variable, ce qui permettrait de tracer le graphe complet des interconnexions même dans une présentation en liste tabulaire). iD de son côte ne propose rien de ce côté. Il ne reste alors que les vérificateurs en ligne, après sauvegarde dans la base (mais avec un délai de 10 minutes avant de pouvoir faire les corrections si l'outils en ligne "suit" les modifs au fil de l'eau, sinon parfois plusieurs jours). Le 1 août 2013 22:48, PierreV <belett...@hotmail.fr> a écrit : > Tiens... cet aprèm j'ai fait une mini formation a une stagiaire du parc du > marais poitevin qui voulait créer un trajet cyclable... la solution est > d'utiliser une relation (et c'est pas le plus simple de former directement > quelqu'un sur les relations...) > JOSM a encore un avantage sur cette nouvelle version d'ID pour l'édition > avec la visualisation de l'ordre des chemin et de signaler si les chemins > sont tous connectés entre eux... > > > > -- > View this message in context: > http://gis.19327.n5.nabble.com/iD-1-1-arrive-tp5772191p5772283.html > Sent from the France mailing list archive at Nabble.com. > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
