Les lignes qui se chevauchent sont difficiles à voir

[bpeel]

Bonjour !

Sur la carte avec toutes les lignes, c’est un peu difficile de suivre le tracé des lignes qui se chevauchent. Par exemple la VL9 semble n’avoir que la partie au nord-est parce que sa traversée du centre-ville est entièrement partagée avec d’autres lignes qui sont montrées à sa place.

Je pense que dans l’idéal, quand il y a un tronçon partagé, les lignes seraient toutes visibles en parallèle comme sur la carte du métro de Paris, mais j’imagine ce serait difficile à réaliser avec MapLibre.

Faute de mieux, j’ai tenté de faire une version où quand la souris passe sur une ligne, la couleur de tous les tronçons avec lesquels elle est partagée prennent sa couleur. Je l’ai mise dans une branche ici. Je n’ose pas l’envoyer comme PR parce que je ne sais pas si c’est une bonne idée ou pas, mais ça pourrait être un point de départ pour une discussion.

Capture.video.du.2024-11-15.22-37-30.mp4

[TFCx]

Pour info, c'est une des changements que j'ai effectué sur mon fork. Il est possible (au prix de quelques expressions maplibres un peu chiantes à écrire) de faire des lignes parallèles.

Je peux essayer de faire une MR mais ça impliquait de pré-traiter les segments pour les découper en "tronçons multilignes"... Le code n'est pas ouf mais est améliorable je pense (et pourrait être une base pour une MR propre).

Par contre, un soucis qui peut apparaitre c'est qu'elle se croisent (admettons 2 tronçons contigues, suivant comment les coordonnées sont données, les lignes pourraient être VERT-JAUNE puis JAUNE-VERT).

[bpeel]

Excellent ! La carte est très jolie comme ça 🤩 J’espère que ça pourra être intégré à la carte lyonnaise.

[ThibautChd]

Les deux propositions de Neil et Jean-David sont chouettes !

Concernant celle de Neil, je pense qu'elle a du sens si tous les tronçons de la ligne prennent sa couleur uniquement au survol de la souris. Ainsi, une fois que le survol de la souris a quitté le tronçon, on retrouve la visualisation par défaut. Il faut savoir que cette vue par défaut a été murement réfléchie pour faire privilégier la ligne principale par défaut. On a la même logique que dans les transports en commun : quand certaines lignes de tram empruntent une tronçon en commun, on a tendance à toujours l'appeler par le même nom, car c'est celui qui vient en tête en premier quand on pense à cet endroit.

Avec la proposition de Jean-David, je vois plusieurs limites majeures pour le moment. Si on arrive pas à avoir le même rendu dans l'ordre des couleurs d'un tronçon à l'autre, on va avoir un rendu crado, d'autant plus que la version lyonnaise à de très nombreux tronçons qui se succèdent sans qu'on change de lignes en commun. En outre, on a de nombreux tronçons avec 3 lignes en commun, et même un avec 4 lignes. J'ai peur que cela fasse un rendu "gros pâté" avec un trait trop épais rendant difficilement lisible le tout. Il faudrait en tout cas tester cela et faire pas mal de corrections de code avant d'avoir un rendu satisfaisant, ce qui implique un gros boulot. Comme ce genre d'amélioration "nice to have" n'est pas une priorité pour l'équipe lyonnaise, on suivra vos propositions avec attention mais on préfère prioriser le peu de dispo qu'on a sur d'autres sujets plus importants à nos yeux.

[TFCx]

Actuellement, le rendu se fera dans le sens de définition du tronçon, de la ligne avec le numéro le plus petit à la ligne avec le numéro le plus grand. Donc l'emplacement de la ligne n'est pas optimisée pour minimiser les décalages. Ca c'est un problème assez complexe (j'ai souvenir d'un très long article sur le rendu des lignes de métro de SF sur iOS...). 😰

Je vais essayer de te montrer ce que ça donnerait avec les lignes lyonnaises.

[ThibautChd]

Coucou @TFCx !
As-tu pu avancer sur ce rendu lyonnais pour améliorer l'affichage des tronçons communs ? :)

[TFCx]

Oups, j'ai oublié de faire ce test.

J'avance comme je peux. 😅 J'ai passé quelques jours à débloquer Chambery histoire qu'ils puissent communiquer pour la période du baromètre ; ça me semblait + prioritaire.

Côté Montpellier, j'ai presque fini de réecrire tout le code de visualisation, à la fois pour corriger quelques petits pbs, l'améliorer à mes yeux, et gérer des trucs un peu + complexes. Et j'ai changé le fond de carte que je trouvais problématique pour nos futurs développements.

Ca donne ça sur Montpellier (avancement du projet & futur réseau complet) :

Pour Lyon, avec des "vieilles" données (21 juillet 2024) ça donne ça :

Et je vois qu'il y a quelques soucis dans l'annotation de certains tronçons, d'où quelques bugs graphiques (1 ligne, 2 lignes, 2 autres lignes, 4 lignes, 2 lignes) ?

[ThibautChd]

Sacré boulot Jean-David, chapeau !

Aucun problème d'avoir priorisé Chambéry, c'est tout à fait normal !
Merci pour les rendus sur ta refonte du module carto, avec la version lyonnaise. On voit bien la difficulté à gérer le rendu du multi-lignes sur des tronçons qui se suivent.
Bien vu pour l'anomalie sur le tronçon "Porte du Valvert". Je m'occupe de corriger ça.

A priori on devrait pouvoir se passer de ta refonte carto dans un premier temps sur notre version lyonnaise, nos priorités étant ailleurs. En tout cas ça fait vraiment plaisir de voir l'émulation suscitée par Cyclopolis dans les différentes communes !

A bientôt !
Thibaut

[TFCx]

Pas de soucis. Ca m'a permis de voir d'ailleurs un soucis avec les variantes :) ça fait des gros patés alors que ça ne devrait pas. Et désolé, je viens de me rendre compte que les couleurs des lignes étaient celles de Montpellier. Si j'ai 2min, je referai un test ce soir.

[hverlin]

Quelques améliorations sur le Cyclopolis de Lyon sur ce sujet.

On a ajouté les numéros des voies lyonnaises. Lorsque l'on clique sur un segment, on réduit l'opacité des lignes qui n'utilisent pas ce segment. J'ai pas encore testé d'implémenter les lignes superposées comme Montpellier.