Ajouter de nouvelles régions

[laem]

Tester les nouvelles régions qui publient des jeux de données agrégés sur transport.data.gouv.fr ; voir si ça prend 5 minutes, 5 heures ou 5 jours.

Les fichiers GTFS des AOM (autorités organisatrices de transport) sont agrégées pour certaines régions, et pas d'autres.

Dans un premier temps, on va pas se charger d'intégrer les données des petites agglo. Enfin, c'est vous qui voyez :)

Mon objectif est de développer l'offre TeC de cartes.app d'abord sur la Bretagne, peut-être le grand ouest.

[laem]

Bon, de l'eau a coulé sous les ponts. Grâce à mes améliorations de perf de la lib node-gtfs, on passe de 16 minutes à 10 minutes de temps d'injection des données GTFS dans le serveur. On ajoute 5 à 10 minutes de création des plans de transport (optimisable).

Donc pour chaque mise à jour complète des GTFS, ça nous prend 20 minutes quand j'écris ces lignes en octobre 2024.

À côté de ça, Motis est toujours ultra rapide. La question s'est posée plusieurs fois d'abandonner node-GTFS pour plutôt faire des requêtes directement sur Motis. Je pense qu'on pourra se reposer la question quand Motis sortira sa version 2 de l'API comme discuté sur leur canal Matrix.

En attendant, ça me semble compliqué de se passer de ce serveur node qui certes est lent à l'initialisation, mais qui marche.

J'aimerais plutôt maintenant explorer la mise à jour progressive de la base de données. Principalement pour l'usage du test de nouvelles régions. Il faut qu'on puisse tester l'ajout d'un nouveau jeu de donnée en un temps d'itération correct, donc en moins de 2 minutes.

En effet, que l'import du tiers actuel de la France prenne 10 minutes d'import GTFS plus 10 minutes de génération des plans de région, on s'en fout pas mal si c'est fait la nuit. Une heure pour la France c'est acceptable. On pourra même le faire sur un serveur en ligne, surtout si on passe à Deno.

Pour l'instant on supprimait toute la db pour la recréer entièrement. On peut continuer de le faire une fois par jour, et ça semble pertinent car de toutes façons les gros jeux de données sont MAJ tous les jours, cf Bretagne et IDF. Mais c'est relou de devoir attendre la nuit pour voir si un nouveau jeu a marché, et d'ailleurs constater peut-être qu'il a pété l'ensemble.

On a donc deux solutions : tester l'ajout du jeu à la base de donnée centrale, mais avec le risque de la corrompre si ça n'a pas marché.

Tester l'ajout à une nouvelle db indépendante, qui expose elle aussi une URL, et pouvoir tester cartes.app branchée sur cette autre URL.
Ce ne serait pas trop compliqué de variabiliser entièrement la db dans notre serveur et d'ajouter un nouveau serveur express sur un autre port par exemple, mais un peu de boulot quand même.
Reste Motis, sans lui on peut pas vraiment tester l'ajout d'un TeC, et même sans les données OSRM très lourdes on peut pas tester un vrai calcul d'itinéraire. Donc plus compliqué à cloner, on va pas télécharger 30 Go de données de routeur à chaque test d'ajout de réseau...

Donc peut-être qu'on peut rester sur un serveur central, avec une route qui importe un GTFS dans la BDD centrale et qui reparse tout Motis (10 secondes). On partirait alors du principe que si ça marche dans server.js (test sur cartes.app : arrêts de bus et plan de transport en commun), alors c'est que le jeu de données est pas si dégueu et sera correctement chargé dans Motis la nuit prochaine.

[laem]

Via une github action, ou même juste sur une URL serveur.cartes.app/gtfs/add body json au format input.yaml on pourrait lancer l'ajout du jeu dans une base de donnée neuve, ça prendrait de 10 secondes à 5 minutes (Paris), ensuite on produirait un lien vers cartes.app/?dev qui taperait sur le serveur express de dev sur un autre chemin nginx, pour explorer l'ajout. La route pourrait également lancer motis.

Resterait ensuite à tuer ces tests, ou plutôt on reposerait sur l'idée qu'il n'y en a qu'un qui tourne.

Quel intérêt, par rapport à un test en local ? Pas beaucoup en fait :/ Ça permettrait juste de rendre autonome les non-dev ou contributeurs passagers qui pourraient alors merger un jeu de données s'il s'affiche bien. Mais ça n'a que peu d'intérêt par rapport à la possibilité de tester en local 1 réseau majeur toutes les 5 minutes, en 1h on a ajouté le reste des métropoles de France, celles qui marchent bien.

Par exemple, j'ai tenté l'ajout de Nancy et Lille en mergeant des PR, mais ils n'apparaissent pas. Il faut débugger, et ça passe par du travail en local.

On a beaucoup de choses à faire notamment sur le passage à motis v2 et la branche iti2, donc automatiser le déploiement de nouveaux réseaux ne me semble finalement pas si prioritaires car pas du tout trivial, vu l'impossibilité de faire tourner un build reproduit entièrement de toute l'application à chaque PR (des centaines de giga à télécharger sur une machine très chère).

Voilà voilà :D

[laem]

Par contre, une chose à faire au plus vite, c'est gérer le processus de mise à jour dans un autre serveur. Et faire un swap des DB (les données motis comme le GTFS, mais surtout d'abord le GTFS) en 10 secondes une fois que c'est fini et validé.

•  Faire la MAJ des GTFS en dehors du serveur principal #44