Gares ferroviaires (France) : en service, fermées ou déclassées ou disparues 1925-2021
1. Introduction
Un objectif
Ce travail a pour ambition de présenter l'évolution du paysage ferroviaire français.
Il est réalisé à partir de données publiques et de multiples données ouvertes (Wikipedia, données volontaires ...).
Plus de 11000 gares, haltes ou simples "arrêts" et des milliers d'embranchements, ont été géo-localisées sur plus de 1500 lignes.
La "géo-localisation" permet d'associer chaque gare à d'autres données :
. la page Wikipedia de sa gare, si elle existe, parfois des photos,
. sa position sur une ou plusieurs lignes, des calculs de chemin, distance, etc..
. sa commune et les informations afférentes INSEE, population concernée, etc.,
Certaines lignes secondaires ou tramways ruraux, souvent en voie métrique, ne sont pas reliées au réseau principal,
mais ont des connexions, exemple : un arrêt de tramway face à une gare.
Naviguez sur la cartographie : actuelle versus réseau "reconstitué" de 1830 à nos jours
Visitez vos territoires préférés, vos lieux de vacances, vos souvenirs d'enfance ... et n'hésitez pas à signaler les erreurs, les oublis, etc... Notes : Le premier affichage peut prendre 10-20 sec. Le javascript de Safari (versions anciennes) ne fonctionne pas.
|
|
Le fichier
"gares du reseau ferroviaire francais en service, fermees ou disparues,
est au format GeoJson,
sous licence libre ODbL,
déposé sur data.gouv.fr.
La variété des formats des sources : tables type Excel, InfoBox-Wikipedia, listes de coordonnées (eg. OpenStreetMap), etc...
a imposé le développement d'outils informatiques de complexité variée : du simple transcodage,
à la recherche en cascade de pages hypertexte contenant les informations de localisation.
Et beaucoup de vérifications, "visuelle" et "manuelle", mais forcément des erreurs subsistent.
Certains départements ne sont pas totalemeny renseignés : il reste probablement quelques centaines de gares à géolocaliser.
Crédits : travail commencé avec les étudiants du Dept. Informatique de l'IUT de Marne-la-Vallée (2016-18)
2. Les sources utilisées
Les sources principales, SNCF ou la Plateforme ouverte des données publiques françaises, sont accessibles par programme (API). D'autres sources proposent des données tabulées (eg. code HTML pour des tables),
ou des données qu'il faut extraire de fichiers texte (eg. pdf). Les sources photographiques sont simplement "observables" visuellement (eg. anciennes photographies aériennes IGN),
... toutes sont inestimables.
SNCF : informations sur les gares et les lignes encore sous le contrôle de la SNCF.
Les fichiers énumèrent près de 6500 gares et plus de 1700 tronçons de lignes.
Insee : limites communales (polygone), historique des fusions de communes ....
Le polygone des limites communales permet de savoir si un point géographique est sur le territoire de cette commune. L'historique des créations, fusions, permet de suivre une évolution éventuelle avec la date d'une autre source de données.
IGN : remonterletemps.ign.fr (carto et photos aériennes de l'après-guerre à nos jours)
le site "remonterletemps.ign.fr" ... comme son nom l'indique, donne accès à des informations géographiques historiques (plus particulièrement pour les années 1947-1960)
et permet la comparaison visuelle avec les données récentes (années 2000-2018).
Exemple : la gare de Les Trillers, la plus proche (probablement) du centre de la France métropolitaine.
Wikipedia : des milliers de pages (semi-structurées) de Gares et de Lignes.
Les informations fournies, souvent très complètes, permettent de lier gares et lignes, mais aussi autoroutes et cours d'eau (ponts), tunnels etc.
Elles ont l'avantage d'être "semi-structurées" selon une sémantique en partie normalisée, notamment pour les coordonnées du point géographique associé (s'il existe) et pour les "InfoBox" des Lignes.
Exemple: la page Gare des Trillers indique "située au point kilométrique (PK) 318 de la ligne de Bourges à Miécaze,
ce qui conduit à examiner la page cette ligne, où on apprend qu'elle porte le "numéro officiel 695 000
ainsi, de ligne en ligne, d'arète en arète, ou d'arète en noeud, la suite est fort longue dans ce graphe (pas tout à fait planaire).
En sus de ces informations semi-structurées, on trouve de nombreuses pages sur l'histoire des lignes ferroviaires comme Liste des chemins de fer à voie métrique de France, ... plus difficiles à décoder par logiciel mais qui nous informent sur l'existence de centaines de gares, non encore repertoriées. Voir aussi l'Rails & histoire (Association pour l'histoire des chemins de fer), ou trainvapeur.fr sur l'histoire des chemins de fer, ...
Données participatives volontaires ("crowdsourcing" ou "wiki")
Nombreux sites, personnels ou collaboratifs (de type "wiki"), alimentés par des amoureux du rail ou du patrimoine des transports en général : voici les principaux sites utilisés (ordre alphabétique).
etc.... Cette liste est enrichie en fonction de vos signalements
passages frontaliers : sources des compagnies des pays voisins.
les liaisons ferroviaires frontalières ont été complétées à partir des sites des réseaux ferroviaires voisins : SNCB, CFL, DB_Nerz ...
3. Fusion des sources
L'objectif
est de créer un ensemble de jeux de données (fichiers GeoJson) contenant des informations permettant la cartographie (coordonnées), mais aussi l'analyse conjuguée des données gares et lignes entre elles ou avec des données administratives (eg. département), ou sociales (eg. population concernée) issues de recensements, etc.
Pour fusionner deux sources d'information semblables on doit trouver un identifiant commun
(une "clé primaire" au sens SGBD systèmes de gestion de bases de données).
Pour une gare il peut s'agir du nom "officiel" ou du code UIC (union internationale des chemins de fer).
Pour une ligne, le couple de gares origine-terminus, ou le numéro "officiel" peuvent être une clé.
Pour fusionner deux sources d'information différentes (gares / lignes / communes)
il faut qu'au moins une des sources possède aussi la clé d'une autre source (une "clé externe").
Dans le cas idéal,
on devrait pouvoir reconstituer le schéma suivant, classique des SGBD :
Mais dans la réalité,
il faut transiger avec les données telles qu'on les rencontre : incomplètes, de qualité incertaine, ...
Heureusement, les coordonnées géographiques peuvent jouer un rôle semblable à une clé,
par l'intermédiaire de certaines relations géométriques (eg. intersections points -lignes - polygones).
Un inconvénient est que ces calculs sont plus coûteux qu'une simple comparaison de clé.
Ils sont également sensibles à des erreurs de précision.
Examinons les principales clés :
clé de gare : code UIC (Union Internationale Cheminsde fer), ou libellé
le code UIC est unique, mais il n'est présent que dans les sources SNCF, l'identification se fait souvent par le libellé (toponyme).
Un problème est la non-unicité (eg. Saint-Prix est une commune dans six départements !),
les artifices pour distinguer les libellés ne sont pas normalisés (eg. Laroche - Migennes ou Laroche-Migennes, Paris-Nord ou Paris Gare du Nord),
les orthographes peuvent varier (eg. accents), etc.
clé de ligne : numéro officiel, ou couple origine - terminus (libellés de gares)
le "numéro officiel" est plus largement répandu, a condition d'être cité, ou même simplement attribué.
Les lignes qui n'ont jamais été gérées par la SNCF n'en possèdent pas. Il faut leur attribuer de nouveaux codes, arbitrairement mais sans créer de conflit avec l'existant.
Le couple [origine, terminus] est pertinent, mais soulève les problèmes des libellés de gares, vus précédemment.
Exemple : le Chemin de fer de Dompierre à Lapalisse
démarre à la gare de "Dompierre-Sept-Fons"
et se termine à celle de "Lapalisse - Saint-Prix", toute deux dans le département de l'Allier.
La gare qui a pour libellé "Dompierre" est située dans le département du Nord.
clé de commune : code Isee, ou nom toponymique
le "code commune" unique est attribué par l'Insee. mais il est rarement présent dans d'autres sources (le code postal est plus fréquent). Il faut souvent le retrouver à partir du toponyme, ou des coordonnées géographiques et dans les deux cas il peut y avoir des erreurs. Dans un nombre non négligeable de cas, il peut avoir changé si les dates de création des sources différents de quelques années.
dates : dates "réelles" (eg. ouverture d'une ligne), ou dates de mise à jour d'un fichier.
les dates sont importantes. Il faut distinguer deux types de datation :
- celle de la création des sources : utile pour évaluer la cohérence des informations à fusionner (cf. exemple ci-après),
- celle des événements eux-mêmes (eg. fermeture d'une ligne) : pour analyser l'état du réseau ferroviaire aujourd'hui, ou il y a 20 ans, ou durant la IVème République, etc.
Hélas, elles sont rarement présentes sous une forme normalisée (eg. InfoBox des lignes dans wikipédia, quelques "crowdsources"), souvent imprécises ou même carrément absentes.
Exemple : le fichier des gares SNCF indique sa date de dernière mise à jour (eg. 2019),
mais les toponymes présent peuvent indiquer des communes qui ont été modifiées entre temps (un milier entre 2015 et 2018).
Il devient difficile de savoir combien il y a de communes en France, à une date donnée.
Conclusion
Développer les outils permettant de manipuler les clés citées ci-dessus, ou leurs équivalents les plus proches, relève du "génie des données" ("data engineering"), qui dépasse largement le champ des SGBD. Mais il constitue la première étape indispensable dans la réalisation du projet.
4. Les outils développés
Données (quasi-) idéales : vérification de contraintes et jointures de tables.
Certaines données des sources précédentes, sont explicitement géocodées et identifiées avec une clé unique, dans ce cas elles sont directement utilisables.
Une simple transformation de format sera appliquée afin de normaliser leur structure dans l'attente d'attributs complémentaires issus d'autres sources. Les trois principales fonctions sont :
(1) renommer les propriétés de manière harmonisée,
(2) s'assurer que les types sont identiques (identifiants parfois numériques, ou avec lettres),
(3) s'assurer de l'unicité de la clé (sauf équipements distincts d'une même gare sur plusieurs lignes).
Dans ce cas très favorable, la "jointure" (SGBD) permet de relier deux sources quelconques.
En cartographie, on aime bien les graphes planaires qui facilitent certains calculs (eg. ne pas traiter deux fois la même ligne).
Pour représenter correctement un graphe dont les noeuds sont les gares et dont les arêtes sont des tronçons de lignes, il faut s'assurer que :
(4) chaque arête est identifiée par un noeud début et un noeud fin. Donc une gare de correspondance doit apparaitre sur chacune de ses lignes : vérifier et dupliquer si besoin.
S'il s'agit d'une bifurcation, un noeud doit (devrait) aussi figurer sur chaque ligne (vérifier et dupliquer si besoin).
(5) les intersections (géométriques) d'arêtes correspondent à des noeuds : vérifier et corriger éventuellement.
Seule exception : certaines intersections ne sont pas des "croisements", mais des superpositions (passages supérieurs/inférieurs en troisième dimension).
Identifier ces superpositions permettrait de les isoler et d'obtenir un graphe mineur
planaire à une échelle plus locale (par exemple en retirant les lignes LGV).
Données de mauvaise qualité ou absentes : fusion semi-automatique seulement.
Pour les nombreuses informations qui n'offrent que des clés incomplètes ou incertainnes, et pour celles qui ne sont qu'indirectement localisées (toponymes, codes de lignes SNCF ...),
on parle de fusion des données, vue alors comme une généralisation des "jointures" (SGBD).
Dans le royaume des données (la "data science" en général) on découvre vite que le diable est dans les détails, ou selon un idiome plus proche du sujet : un grain de sable peut faire dérailler le train.
L'intelligence artificielle (dans sa version apprentissage profond) n'est pas bien armée pour entrer dans les détails, car la création de corpus d'apprentissage est difficile dans les cas évoqués,
qui sont -heureusement- des exceptions, mais -malheureusement- très diverses.
La seule solution est de multiplier les jointures partielles entre des données de sources différentes afin de compléter l'information recherchée "de proche en proche".
La difficulté n'est pas d'ordre mathématique, mais dans la mise en oeuvre d'un grand nombre de requêtes, asynchrones, dont certaines n'aboutiront pas.
Au stade actuel de ce projet, on ne peut parler que de traitement semi-automatique. Une phase terminale de validation "humaine" est souvent indispensable (environ 30% des cas) à propos de la partie manquante (ou jugée trop incertaine) de l'information : souvent la localisation précise et la date cherchée (eg. date de fermeture d'une ligne).
(1) comparaison des informations sur les gares issues des deux sources :
- "Gares ferroviaires de tous types, exploitées ou non", censé représenter les gares du réseau en 2011, déposé sur "data.gouv.fr",
- "Liste des gares du Réseau Ferré National", dont les données ont été mises à jour en 2019, sur "data.sncf.com" (et non pas: sncf.fr).
L'espoir était que la réunion des gares issues des deux fichiers permette d'augmenter le nombre total de gares et de compléter l'information manquante (notamment les coordonnées géographiques). Les difficultés principales sont venues des différences d'écriture des libellés de gares : accents, positionnement des traits d'union, noms simples ou composés, adjectifs non partagés (ex. nom du département), etc. Les tentatives automatiques (distance de Hamming ou plus complexe) n'ont résolu qu'un faible pourcentage de cas. Trop de cas particuliers.
(2) recherche de la liste des gares d'une ligne :
- nom de ligne connu : recherche InfoBox de la page wikipedia (redirections à prévoir)
- recherche à partir d'une gare connue : recherche d'une page wikipedia éventuelle
(3) recherche des coordonnées :
- gare déjà présente sur une autre ligne : jointure (vérification orthographe, noms composés)
- gare nouvelle : "remonter le temps" positionné sur libellé (vérification orthographe, noms composés)
(4) vérifications :
- ordre correct des points kilométriques dans la ligne (interpolation éventuelle)
- correspondance coordonnées de gares et polygone de la commune qui les contient (cas particuliers limite)
Travaux pratiques : code JavaScript
Exercice 1: (facile) vérifier si la gare la plus proche du "centre (IGN)" de la France est bien celle des Trillers.
Exercice 2: (facile) comparer le centre du nuage des gares avec le centre de la France (situé en Bocage bourbonnais), mesurer le décalage. Idem avec gares en activité versus toutes gares.
Exercice 3: (moins facile) compter combien d'arêtes rendent le graphe du réseau ferré français non planaire.