Plans de transport v2

• Réflexion préliminaire

<details><summary>Dérouler</summary> - changer la structure de agency.points. Nul besoin de lourds geojsons, juste des tuple [nom de l'arrêt, id, position] - à partir de là côté client on peut aggréger les arrêts par nom pour créer une table nom -> barycentre du groupement d'arrêts - un groupement peut être les deux sens d'un bus simple ; 4 arrêts de deux bus qui s'arrêtent au même lieu mais à quelques dizaines de mètres ; des pôles de transport comme République à Rennes - puis le faire aussi en prenant en compte la géoloc (pour éviter de regrouper "stade" au nord de la ville et "stade" au sud) - les polylines doivent maintenant faire référence aux points via leurs id et donc à la table points - actuellement on a d'un côté : - la liste des noms d'arrêt : pour l'interface uniquement je suppose avec le désavantage de ne pas être cliquable - la polyline qui représente le tracé calculé par notre serveur - dans quel sens se fait ce tracé ? On prend au hasard l'une des directions en ignorant donc totalement l'autre ? - non, c'est plus simple : on prend les stops du trip qui en a le plus ! L'omnibus. - on pourrait faire de même pour l'autre sens : à partir d'un certain zoom, l'utilisateur verrait alors deux lignes pour le bus C1 ; et surtout avant de zoomer, il verrait comme arrêt de la ligne unique le barycentre des arrêts des deux sens, ce qui est bien plus pertinent qu'un sélection au pif de la direction </details>

• Nouveau schéma des plans d'agence
• première version du dessin de l'agence Star en mode symbolique (zoom faible), en reconstruisant les segments à partir du couple routes, stopNames. Prioritaire : ça permettra de valider ou nom notre schéma de données et design d'ensemble
• je crois que le calcul des computeFrequencyPerDay est complètement pété haha. À revoir.

Adapter l'interface

De mémoire les fonctions d'enrichissement en vue de l'affichage étaient assez lourdes.

On va distinguer 3 niveaux de zoom.

Faible

Par agence, on n'affiche que les "meta arrêts" de bus. Quand une route a un segment entre deux meta et qu'une autre a la même chose, on les affiche en parallèle. Pour ça, créer une map a1->a2 : [routes]. Possible que ça fasse ronronner les ordinateurs sur les grosses agences comme à Paris, à voir. On pourra le faire côté serveur si c'est le cas, même si ça pourrait augmenter la taille du transfert de données (Geojson donc) avant compression.

L'ordre doit être géré : une route qui est au-dessus de A à B ne soit pas passez en-dessous de B à C. Pas dur.

On a le droit à l'erreur, ce sera je pense dans tous les cas vachement mieux que l'existant.

Il faudra gérer le clic sur une route : est-ce qu'on filtre l'affichage en gardant cette agrégation, ou est-ce qu'on passe au réel ?

Même souci pour les directions que ci-dessous.

Moyen (optionnel)

On affiche les routes avec leurs arrêts réels mais agrégés pour les deux directions : pour chaque arrêt, barycentre entre les deux. Pas trivial, car il faut grouper les arrêts par couples : on peut s'en occuper dans un second temps.

Fort

On affiche les deux directions de chaque route dans la même couleur, si possible en affichant sur la carte une ellipse sur les couples d'arrêts. C'est facile en apparence... mais !

Partie difficile : comment éviter que ne se chevauchent les routes qui partagent précisément le même tracé sur certains segments ? Beaucoup d'arrêts de bus partagent deux routes. N'a-t-on pas intérêt à appliquer tout simplement le même algo que pour le zoom faible, mais avec le stop_id comme clef de la Map ? Ça mérite très clairement d'être testé !

Autre option plus facile : on ne trace les routes exactes qu'au clic sur une route, en mode focus. Moins puissant, mais peut-être plus simple pour l'utilisateur, et on concentre les efforts sur le mode symbolique

C'est parti

• ajouter les arrêts
• blancs (pôle d'échange) ou couleur
• chevauchement C1 & C2 entre croix-saint-hélier et gares ?
• rétablir l'importance des lignes pour comparer avec le plan de Rennes, potentiellement factice avec "C" et autres filtres pour comparer à "lignes urbaines"
  • en fait, compliqué de faire marcher ça sans rétablir le clic sur les lignes, qui permet d'explorer les données directement depuis l'app en dev plutôt qu'à la main dans le GTFS
• si nettement plus satisfaisant que l'actuel, go go go tout coder !

Tout coder

• intégrer les route_desc dans la fiche ligne, très utiles à Rennes
• gérer l'affichage détaillée des lignes (zoom fort)
• faire marcher sur Rennes la diversité des types de lignes : nuit, etc.
  • rétablir l'affichage du filtrage des lignes sur le plan (en gardant les arrêts globaux ? ) ; d'une ligne au clic sur la ligne ; des lignes d'un arrêt
  • définir la taille des arrêts sur l'ensemble du réseau, puis n'afficher que les arrêts des lignes sélectionnées. Donc extraire la création des features depuis drawTransitMap dans une fonction à réutiliser en amont, juste les filtrer au draw
• implémenter le plan pour les autres villes, avec choix automatique de la gamme de lignes : si plein de métros + tram + BHNS (comment les repérer, comme à Lyon, il y a un type générique ?), pas de bus sur la gamme principale ; puis bus majeurs ; puis évènementiel / nuit / scolaire.
  • Bien sûr l'IDF rame ! Il faudra de belles optimisations pour corriger ça. Mais le métro rend super bien !
• tester l'optimisation par claudecode : plus rapide ++ sur IDF ? quel diff json sur plusieurs agences ? OK c'est bon, elle ne fait une diff' que d'un stop en plus (en mode bouclage du cercle) dans une ligne de bus de nuit de Nantes, bon à savoir mais pas grave. Identique pour Rennes. 2 à 3 fois plus rapide en fonction de la taille du jeu !
• gérer à nouveau la SNCF
  • sur la base du nouveau jeu de données du futur !1143
  • gérer l'affichage : le TGV pose problème !295
  • report à nouveau du sujet train : il faut d'abord qu'on mette en ligne l'actuel demain
• améliorer la perf : Lyon doit être presque instantané, Paris ne ramer qu'un peu
  • réécrire l'affichage de la liste
  • et le calcul des points pour le dessin, très lent
• ainsi que les réseaux nationaux voir européens comme Flixbus / Blabla, à mettre dans un lot groupé
• le nom des arrêts, avec priorité (comment gérer ça, dans Maplibre sur le chevauchement ?) aux gros

Par la suite

• breizhgo : lignes trop étroites, on voit pas à fort niveau de zoom
• plutôt que des segments unitaires arrêt A -> arrêt B, coder des segments multiples A->B->C pour éviter que l'offset créée un cassure à B. Maintenir l'offset constant pour une ligne. Idéalement, donner l'offset le plus faible aux lignes qui arrivent et partent à gauche. Haha pas simple 😅
• faire des effets au survol pour distinguer les lignes Eurostar entre-elles par exemple. C'est pas simple : ni setFeatureState (ne permet que de surligner par id, or plein de segments ont le même id) ni setFilter (trop instable) ne suffisent
• les noms des lignes, bien sûr

Le liseré ça rend pas bien. Générer une palette de couleurs à partir des couleurs en conflit ?

• représenter les superpositions comme avec une ombre portée sur la ligne qui se fait superposer, pour montrer l'addition en relief. Line-gap-width ?

Encore plus par la suite

• les parkings relais, depuis OSM
• facile d'intégrer les parkings vélos comme on le fait dans useTransportStopData ?