Que peut-on conclure, et que ne peut-on pas conclure, à partir d'une carte des arrêts du RTC?
Source : Données Québec / Réseau de transport de la CapitaleLicence : Attribution (CC-BY 4.0) selon les métadonnées CKAN; conditions RTC à respecter pour la provenance et la date de mise à jourTéléchargé : 2026-06-21
Pour travailler GTFS, Données spatiales, Unité statistique, Valeurs codées à partir d’un contexte mobilité et transport collectif lié à Territoire desservi par le Réseau de transport de la Capitale, région de Québec.
GTFSDonnées spatialesUnité statistiqueValeurs codéesimportation d'un ZIPdonnées relationnelles
Ce que les étudiantes et étudiants font
Cartographier les arrêts du RTC et discuter la couverture spatiale sans inférer la demande.
Comparer les parcours selon le nombre de trajets planifiés et les limites de cette mesure.
Construire un dictionnaire relationnel reliant stops, routes, trips, stop_times et calendar_dates.
À cadrer en classe
Faire expliciter que le code d'accessibilité 0 signifie information non disponible dans GTFS.
Aperçu des données
Entrer par les lignes, puis poser une question
Extrait public de la table préparée à partir de la source officielle, limité à 120 lignes pour une exploration rapide.
TerritoireTerritoire desservi par le Réseau de transport de la Capitale, région de Québec
NiveauIntermédiaire
FormatZIP GTFS contenant des fichiers texte CSV
Documentation complèteSources, variables, code R minimal, méthode et limites
Pourquoi ce jeu est intéressant
Ce jeu place les étudiants devant un vrai flux GTFS statique : un ZIP officiel qui contient plusieurs fichiers texte reliés entre eux par des clés. Il force à réfléchir à l’unité statistique avant de compter, cartographier ou joindre les tables.
Le RTC publie des informations sur les arrêts, les horaires et les parcours en formats GTFS et shapefile. Le GTFS est utile en science des données parce qu’il combine structure relationnelle, coordonnées spatiales, calendriers de service, valeurs codées et gros volumes de lignes.
Question d’analyse : comment décrire l’offre planifiée du RTC sans la confondre avec l’achalandage ou les retards?
Ce qui a été vérifié
Élément
Résultat vérifié
Paquet CKAN
a6ad0f52-9699-43ed-9907-791472badc19
Source officielle
Données Québec / Réseau de transport de la Capitale
Ressources dans le paquet
2 ressources : GTFS et shapefile
Ressource préparée ici
googletransit.zip
Licence CKAN
Attribution (CC-BY 4.0), selon les métadonnées CKAN consultées le 2026-06-21
Conditions RTC
Indiquer la provenance et la date de mise à jour des informations publiques utilisées
Territoire desservi par le Réseau de transport de la Capitale, région de Québec
Couverture temporelle observée
Services planifiés du 2026-06-20 au 2026-08-21 dans feed_info.txt
Le GTFS Schedule est un format composé de fichiers texte dans un ZIP. La documentation officielle de MobilityData décrit les fichiers de base comme agency.txt, routes.txt, trips.txt, stops.txt, stop_times.txt, calendar.txt et calendar_dates.txt.
Ce que représente une ligne
L’unité statistique dépend du fichier GTFS utilisé.
Fichier
Une ligne représente
stops.txt
Un arrêt ou lieu d’embarquement
routes.txt
Un parcours public du réseau
trips.txt
Un trajet planifié pour un parcours et un service
stop_times.txt
Un passage prévu d’un trajet à un arrêt
calendar_dates.txt
Une date de service ou une exception de calendrier
shapes.txt
Un point ordonné dans la géométrie d’un tracé
Une ligne n’est pas un usager, une validation de titre, un retard, une plainte, ni une mesure de satisfaction.
Variables principales
Variable préparée
Rôle
Point de vigilance
stop_id
Clé d’arrêt dans stops.txt
Clé de jointure avec stop_times.txt
stop_name
Nom public de l’arrêt
Peut se répéter selon les directions
latitude, longitude
Coordonnées de l’arrêt
Utiles pour une carte, pas pour mesurer la demande
wheelchair_boarding
Code GTFS lié à l’embarquement en fauteuil roulant
Le code 0 signifie information non disponible
route_id
Clé de parcours dans routes.txt
Clé de jointure avec trips.txt
route_short_name
Numéro public du parcours
Plus lisible que route_id
route_type
Type de transport codé par GTFS
Le code 3 correspond au bus
trip_id
Clé de trajet planifié
Granularité fine, volumineuse
service_id
Clé de calendrier de service
À relier à calendar_dates.txt
service_date
Date de service préparée
Extraite du format YYYYMMDD
RÉSULTATS R
Les résultats ci-dessous proviennent de preparation.R, exécuté sur le ZIP téléchargé le 2026-06-21.
Indicateur
Valeur
Ressources CKAN documentées
2
Fichiers dans le ZIP GTFS
10
Arrêts dans stops.txt
4 370
Parcours dans routes.txt
182
Trajets dans trips.txt
70 876
Horaires d’arrêt dans stop_times.txt
3 104 289
Points de tracé dans shapes.txt
473 328
Transferts dans transfers.txt
753
Dates de service
63
Identifiants de service
22
Première date de service
2026-06-20
Dernière date de service
2026-08-21
Inventaire du ZIP GTFS
Fichier
Lignes
Taille approximative
stop_times.txt
3 104 289
174,8 Mo
shapes.txt
473 328
16,7 Mo
trips.txt
70 876
8,0 Mo
stops.txt
4 370
0,7 Mo
transfers.txt
753
0,01 Mo
routes.txt
182
0,03 Mo
calendar_dates.txt
63
0,002 Mo
agency.txt
1
0,0002 Mo
feed_info.txt
1
0,0002 Mo
calendar.txt
0
0,0001 Mo
Lecture pédagogique : stop_times.txt domine le volume. Pour un laboratoire court, il vaut mieux commencer par stops.txt, routes.txt, trips.txt et des résumés préparés.
Cette table décrit l’offre planifiée dans le flux téléchargé. Elle ne mesure pas la fréquentation des parcours.
Accessibilité selon les codes GTFS
Table
Code
Interprétation
Lignes
Pourcentage
stops
0
Information non disponible
2 591
59,3 %
stops
1
Accessible selon le codage GTFS
1 779
40,7 %
trips
0
Information non disponible
40 792
57,6 %
trips
1
Accessible selon le codage GTFS
30 084
42,4 %
Point important pour les étudiants : un code 0 n’est pas une preuve de non-accessibilité. Il indique que l’information n’est pas disponible dans ce champ GTFS.
Lecture statistique
Une analyse prudente suit cet ordre :
choisir le fichier GTFS qui correspond à la question;
identifier l’unité statistique de ce fichier;
vérifier les clés avant toute jointure;
distinguer offre planifiée, réseau physique, passages prévus et données temps réel;
cartographier les arrêts sans interpréter la carte comme une carte de demande;
rapporter la date du ZIP utilisé, car le flux est vivant.
Les données permettent de décrire une offre planifiée publiée. Elles ne permettent pas, seules, d’estimer l’achalandage, les retards, les temps d’attente réels ou l’équité d’accès au réseau.
Concepts enseignables
importation d’un ZIP officiel;
lecture de fichiers texte GTFS;
clés primaires et clés de jointure;
séparation entre tables de référence et tables volumineuses;
coordonnées spatiales simples;
valeurs codées et dictionnaire de variables;
résumés par parcours;
communication prudente des limites.
Score zéro déchet
Dimension
Score
Justification
Contexte québécois
3
Flux officiel du RTC pour la région de Québec
Accessibilité pédagogique
2
Structure riche mais relationnelle
Qualité documentaire
3
Données Québec, page RTC et documentation GTFS
Potentiel de nettoyage
3
Dates, codes, gros fichiers et jointures
Potentiel de visualisation
3
Cartes d’arrêts, barres, schémas relationnels
Potentiel de statistique descriptive
3
Résumés naturels par parcours, service et code
Potentiel d’inférence
1
Non adapté seul à l’inférence sur la demande
Potentiel de modélisation
2
Base utile pour graphes ou accessibilité, avec données complémentaires
Potentiel éthique
3
Risque de surinterpréter couverture, accessibilité et équité
Réutilisabilité
3
Utile en importation, données ouvertes, transport et visualisation
Total : 26 sur 30.
Activité courte
En 45 à 60 minutes, cartographier les arrêts du RTC et expliquer ce que la carte permet et ne permet pas de conclure.
Activité longue
En 2 à 3 heures, construire un mini-rapport sur l’offre planifiée par parcours, en reliant routes.txt, trips.txt et calendar_dates.txt, puis en discutant les limites.
Code R minimal
À exécuter depuis la racine du projet.
# Load librarieslibrary(dplyr)library(ggplot2)library(readr)# Download and prepare official GTFS resourcesource("datasets/transport-collectif-gtfs/preparation.R")# Import prepared tablesstops <-read_csv("data/processed/transport-collectif-gtfs/arrets_gtfs_rtc.csv",show_col_types =FALSE)routes_summary <-read_csv("data/processed/transport-collectif-gtfs/resume_parcours_gtfs_rtc.csv",show_col_types =FALSE)# Map stops with ggplot2ggplot(stops, aes(x = longitude, y = latitude)) +geom_point(alpha =0.35, size =0.7) +coord_equal() +labs(x ="Longitude",y ="Latitude",title ="Arrêts du RTC dans le flux GTFS",subtitle ="Carte d'arrêts, pas carte d'achalandage" )# Identify routes with the most planned tripsroutes_summary |>arrange(desc(n_trips)) |>select(route_short_name, route_description, n_trips, n_services) |>slice_head(n =10)
Limites et précautions
Le GTFS statique décrit l’offre planifiée, pas les positions en temps réel.
Le nombre de trajets planifiés n’est pas un nombre d’usagers.
Le nombre d’arrêts dans un secteur ne mesure pas directement l’accessibilité vécue.
Les codes d’accessibilité doivent être lus selon la spécification GTFS; le code 0 signifie information non disponible.
Le flux peut changer. Une analyse reproductible doit archiver la date du ZIP utilisé.
Pour analyser les retards, il faut une source GTFS Realtime ou une archive de temps réel, pas seulement ce ZIP statique.
Extensions
Construire une carte des arrêts avec un fond de carte municipal.
Comparer les parcours selon le nombre de trajets planifiés.
Produire un schéma relationnel des fichiers GTFS.
Joindre les trajets aux dates de service pour comparer jours de semaine et fins de semaine.
Discuter ce qu’il faudrait ajouter pour étudier l’équité territoriale ou l’achalandage.