Le 7 septembre 2017 à 09:51, Vincent Pottier <v...@frvipofm.net> a écrit :
> Le 07/09/2017 à 09:35, Jo a écrit : > >> Et chaque rendu transport devra donc refaire ce calcul d'itinéraire >> denouveau et denouveau? >> > Oui. > >> Avec possiblement des résultats divergents entre un moteur de routage bus >> et un autre? >> > Avec nécessairement un rendu différent pour bus et piéton ! Le piéton, il > peut prendre le rond-point à contre-sens ! Oui mais découpage ou pas cela n'a aucune conséquence pour les piétons. Ils ne sont pas le problème du tout. La seule raison de découper est la nécessité de mettre des tags différents sur certaines parties. De plus les piétons ont très des chemins particuliers préférés évitant la boucle et leur demandant d'utiliser des passage protégés écartés du rond-point lui-même: ce sont ces chemins qu'il est intéressant de marquer, ne serait-ce que pour l'accessibilité et la sécurité (donc même les trottoirs périphériques devraient être tracés séparément, la boucle de la chaussée restant dangereuse pour eux même s'ils peuvent en principe l'utiliser on ne peut pas le leur recommander et là il faut être réaliste. > > >> PT_Assistant est là maintenant pour aider à faire la cartographie des >> routes de bus et les maintenir. Je ne dirai pas que c'est tout facile, mais >> ce n'est certainement pas impossible. >> > L'éditeur de relations de JOSM gère très bien les ronds-points (entiers) > intégrés dans un itinéraire, qu'il soit pédestre ou lié aux transports en > commun. Tout à fait d'accord et ce n'est pas le seul outil. Etant donné comment on a fait le choix initial de ne pas taguer les highways comme surfaces mais comme lignes, uniquement pour les véhicules en laissant les piétons à part, que ce soit découpé ou pas cela ne change rien au routage des véhicules sur leur chemin imposé, ni aux piétons qui s'écartent systématiquement de ce chemin théorique "moyen" et qui ne leur correspond pas du tout. OSM progressant en niveau de détail, on en viendra assez vite à tracer *aussi* les surfaces de voiries, tout en gardant le tracé filaire, comme on l'a fait pour les rivières en traçant en plus les "riverbanks". Le filaire pourra encore servir pour des usages plus limités ou moins précis. Mais cela arrivera beaucoup plus lentement en commençant par des zones localisées où le seul filaire est problématique et trop ambigu (et ne permet toujours pas de préciser certains itinéraires autorisés ou ceux qui sont interdits pour les véhicules, ou ceux qui ne sont pas recommandés ou dangereux pour les piétons et pas assez précis en terme d'accessibilité). Car il faut bien admettre que la représentation filaire a aussi ses limites et que ce n'est qu'une modélisation approximative d'une réalité en fait différente et dont la géométrie de base est très difficilement représentable avec juste des tags sur le filaire, dont l'interprétation géométrique devient de plus en plus difficile et ultracompliquée: on a déjà vu le problème récemment pour la représentation cartographique des largeurs de routes et du changement du nombre de "lanes" : comment obtenir une représentation réaliste quand on zoome sur le détail est particulièrement difficile, et jusqu'à présent on n'a que des heuristiques déterminant une largeur estimée moyenne selon le type de route (primary, secondary...) et ne tenant d'ailleurs même pas compte de tags simple comme "oneway=*" qui devrait normalement aussi réduire l'estimation de largeur moyenne. Le tracé uniquement filaire est aussi problématique pour les ponts à chaussées séparés (on a une solution qui commence à s'établir qui consiste à tracer le contour polygonal autour du pont avec man_made=bridge+layer=1, en plus des routes et barrières posées dessus)
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
