Introduction

gapline est un binaire Rust unique qui couvre tout le cycle de vie d’un flux GTFS Schedule : validation, requêtes, édition, scripts. Il tourne hors-ligne, se pilote entièrement en ligne de commande, et s’intègre naturellement dans une CI.

GTFS en un paragraphe

GTFS Schedule est le format ouvert qu’utilisent les opérateurs de transport pour publier leurs horaires. Un flux est une archive ZIP de fichiers CSV (stops.txt, routes.txt, trips.txt, stop_times.txt, etc.) qui décrivent les lignes, les arrêts, les horaires et les tarifs. Si votre application affiche du transport sur une carte, calcule un itinéraire, ou estime une heure d’arrivée, elle consomme un flux GTFS quelque part dans la stack.

Le problème

Travailler avec GTFS aujourd’hui, c’est jongler avec plusieurs outils déconnectés :

• gtfs-validator (MobilityData) — basé sur la JVM, la référence côté validation, mais lourd. Le démarrage à froid de la JVM est lent, la consommation mémoire se compte en centaines de mégaoctets, et il n’y a aucun moyen d’éditer un flux.
• Scripts Python maison — chaque équipe finit par écrire son propre pipeline pour nettoyer les flux (corriger les FK cassées, mettre à jour des coordonnées, retirer des calendriers expirés). Difficile à partager, facile à casser.
• Validateurs web — pratiques pour une vérification ponctuelle, mais ils exigent d’uploader le flux. Pas une option pour des données privées ni pour une CI.

Trois outils, trois workflows, aucune surface partagée. Passer de l’un à l’autre coûte du temps et introduit des dérives.

Ce que fait gapline

Un seul binaire, trois capacités :

• Valider — toutes les règles de GTFS Schedule, groupées par sévérité (ERROR, WARNING, INFO). Chaque anomalie pointe un fichier, une ligne, un champ et une valeur.
• Éditer — lire, créer, mettre à jour, supprimer des enregistrements avec un mini-langage de requête --where. L’intégrité référentielle est garantie avant toute écriture sur disque.
• Scripter — des fichiers .gl enchaînent validation et CRUD en une seule passe, gardent le flux en mémoire entre les étapes, et font une seule écriture atomique à la fin.

Comparaison avec l’écosystème

	gapline	gtfs-validator	transitland-lib
Runtime	Binaire statique unique	Java / JVM	Binaire ou bibliothèque Go
Vitesse de validation (flux typique)	~1×	7–9× plus lent	comparable
RAM sur un flux typique	~8 Mo	~400 Mo	~30 Mo
Opérations CRUD	✅	❌	❌
Scripts	✅ (fichiers .gl)	❌	partiel
Hors-ligne / local-first	✅	✅	✅
Autocomplétion shell avec IDs dynamiques	✅	❌	❌
Licence	core MIT / CLI GPL-3.0	Apache-2.0	MIT

Quand choisir gapline

• Vous faites tourner la validation GTFS en CI et vous vous souciez du temps de pipeline.
• Vous devez corriger un flux programmatiquement, pas seulement le rapporter.
• Vous voulez un pipeline de nettoyage reproductible et versionnable (un script .gl dans votre repo).
• Les données ne peuvent pas quitter la machine.

Étape suivante

Prêt à tester sur un vrai flux ? Le Quickstart prend environ cinq minutes.