Aller au contenu

Flux GTFS

Un flux GTFS Schedule est une collection de fichiers CSV empaquetés ensemble qui décrivent un réseau de transport : lignes, arrêts, horaires, tarifs, tracés. gapline travaille avec les 17 mêmes fichiers définis par la spec GTFS Schedule.

Les deux formes sont acceptées partout où un flux est consommé :

Fenêtre de terminal
gapline validate -f gtfs.zip
gapline validate -f ./gtfs/

Le ZIP est généralement ce que publient les opérateurs. La forme répertoire est pratique pour itérer localement — un unzip gtfs.zip -d ./gtfs/ une fois, puis on travaille directement sur les fichiers. gapline ne demande pas de re-compresser le ZIP entre deux itérations.

Pour l’écriture (via --output, update, delete, ou un save dans .gl), le format de sortie reprend celui de l’entrée : ZIP en entrée, ZIP en sortie ; répertoire en entrée, répertoire en sortie.

Chaque fichier ci-dessous est à la racine de l’archive (ou du répertoire). gapline les parse tous et leur applique les règles de validation.

FichierRequis par la spec ?Cible CRUD
agency.txtRequisagency
stops.txtRequisstops
routes.txtRequisroutes
trips.txtRequistrips
stop_times.txtRequisstop-times / stop_times
calendar.txtConditionnelcalendar
calendar_dates.txtConditionnelcalendar-dates / calendar_dates
shapes.txtOptionnelshapes
frequencies.txtOptionnelfrequencies
transfers.txtOptionneltransfers
pathways.txtOptionnelpathways
levels.txtOptionnellevels
feed_info.txtOptionnelfeed-info / feed_info
fare_attributes.txtOptionnelfare-attributes / fare_attributes
fare_rules.txtOptionnelfare-rules / fare_rules
translations.txtOptionneltranslations
attributions.txtOptionnelattributions

“Conditionnel” signifie qu’au moins un des deux (calendar.txt ou calendar_dates.txt) doit être présent.

Les 17 cibles sont supportées par les commandes CRUD (read, create, update, delete). Les deux orthographes (kebab-case et underscore) résolvent la même cible.

  • Structure des fichiers. Fichier requis manquant, fichier vide, ligne CSV qui ne correspond pas à son en-tête : anomalies ERROR. La validation en aval ne tourne pas de façon pertinente — corrigez ces problèmes d’abord.
  • Clés primaires. Un stop_id, route_id, ou équivalent en double est toujours une erreur. gapline s’appuie sur l’unicité PK pour l’index inverse de l’intégrité référentielle.
  • Clés étrangères. stop_times.stop_id → stops.stop_id, trips.route_id → routes.route_id et les autres FK de la spec sont appliquées. Les orphelins sont des erreurs (sauf calendar_dates.service_id qui référence un service absent de calendar.txt, qui est un avertissement — la spec autorise la définition par dates seules).
  • Champs requis. Valeurs manquantes dans les colonnes requises : erreurs.
  • Colonnes inconnues. Les colonnes non définies par la spec sont des anomalies informatives (unknown_column), pas des erreurs. Les opérateurs livrent souvent des extensions propriétaires ; gapline les préserve en écriture.
  • BOM. Un BOM UTF-8 en début de fichier est accepté silencieusement. Le parser le retire avant l’analyse CSV.
  • Ordre des colonnes. La spec n’impose pas d’ordre ; gapline accepte n’importe quel ordre tant que toutes les colonnes requises sont présentes.
  • Espaces dans les valeurs. Les espaces en début/fin d’une valeur entre guillemets sont préservés. Les valeurs non quotées ne sont pas trimmées.

GTFS est défini en UTF-8. gapline rejette les fichiers non-UTF-8 avec un message clair (quel fichier, quel offset). Si un opérateur livre en Latin-1, transcodez avant de passer le flux à gapline :

Fenêtre de terminal
iconv -f latin1 -t utf8 stops.txt > stops.utf8.txt
  • GTFS-Realtime. Non supporté. GTFS-RT est une spec protobuf séparée ; seul Schedule est couvert.
  • GTFS-Flex et Fares v2. Non supportés actuellement.