Le 22 janvier 2014 21:54, Pieren <pier...@gmail.com> a écrit : > Je n'ai rien contre le principe de ce schéma (même si, effectivement, > ça nécessiterait d'adapter tous les éditeurs, ce dont je doute). > Ce qui reste essentiel, c'est que "routes" (highway) et "voies" (lane) > soient définies par des tags différents. Alors que certains utilisent > abusivement les premiers pour décrire les seconds. >
On a déjà eu le débat avec les rivières, entre le tracé filaire du cours central "moyen" qui décrit la topologie du réseau hydrographique et son sens de circulation, et les riverbanks qui approtent la précision géométrique (mais pas les directions). Si on s'oriente vers un schémas pour les lanes, inutile de surcharger le filaire des voiries (highway=*) avec tout un tas de tags difficiles à interpréter et très instables (confusion fréquente des tags et rôles dans les relations selon le sens "forward" ou "backward". Cela rappelle aussi qu'on a abandonné l'idée des tags avec "left" et "right" pour les relations de surfaces appuyées sur les frontières. Tôt ou tard le schéma "imbitable" des tags "lane" (et l'énorme complexité de modéliser les restrictions d'accès ou de sens ou de franchissement) sera abandonné. Il vaut mieux réfléchir à une autre modélisation des voies de circulation plutôt appuyé sur celui des relations d'itinéraires (relations de type "route" et "route_master"), qui lui aussi devra être simplifié en évitant de traiter les deux sens en même temps (le schéma déconne trop, par exemple sur les itinéraires des lignes de bus, dès qu'il y a le moindre rond-point ou des chemins en Y où la ligne fait demi-tour dans un sens par la même voirie, mais ne réprend pas du tout cette voirie dans l'autre sens). Ce qui permettra alors d'avoir des itinéraires pour les vélos, d'autres pour les poids-lourds, ou les piétons, en s'appuyant pourtant que les chemins tracés. Ainsi dans une relation d'itinéraire de type "route" (où on ne met plus que les chemins pris dans l'ordre, l'itinéraire complet étant dans un route-master pour prendre en compte les itinéraires en Y sans ajouter le même way deux fois), on peut tout à fait modéliser le nombre de lanes dans les rôles; on peut aussi mettre une limite de vitesse dans la relation route, et assembler les différentes routes composantes dans le "route_master" pour prendre ne compte les jeux de chemins ayant des limites différentes de vitesse, ou de largeur, ou de poids. Tout ça reste à réfléchir, mais le schéma actuel des tags "lane:*=" qui mélange tout avec les filaires des voiries ne marche pas bien du tout, il génère trop d'erreurs et est horriblement compliqué à gérer et interpréter. Et géométriquement il est insuffisant aussi dès qu'on est dans des situations de carrefours compliqués. On n'avancera pas tant qu'on ne resimplifie pas à nouveau le schémas filaire de base quitte à avoir un second schéma parallèle pour ne pas casser la compatibilité du schéma de base. On y est parvenu avec les rivières. Le problème se pose avec les voies ferrées (qui ont des séparations physiques du fait qu'un train ne passe pas facilement d'une voie à l'autre, mais c'est horriblement compliqué encore de faire un routage ferré minimum pour les lignes commerciales (qui se fichent pas mal que le train emploie une voie plutôt qu'une autre parallèle et des aiguillages...): le schéma ferroviaire a lui aussi besoin d'une description filaire simple s'appuyant sur une voie déclarée "principale" de façon arbitraire, ne tenant pas compte des éventuels aiguillages sur une voie parallèle, mais tenant compte cependant du sens général de la ligne commerciale avec des relations "route" séparées et faciles à maintenir.
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
