Les points kilométriques ferroviaires en opendata, avec l'altimétrie désormais !

Cet article parle d'un projet personnel entièrement basé sur des données ouvertes.

Voici une mise à jour de ma base de données des points kilométriques des voies ferrées françaises : pour chaque point hectométrique, vous avez également son altitude et la vitesse maximum de ligne. Tout est disponible ici https://github.com/nicolaswurtz/extras-opendata-sncf-reseau en opendata. Corse comprise !

Et bientôt sur ma carto https://carto.tchoo.net mais en attendant, un peu de méthodologie, car ce n'était pas si simple que ça pour l'altitude — je propose d'ailleurs trois champs différents, relatifs aux trois méthodes pour déterminer l'altitude — petite explication de texte...

Nous travaillerons sur la ligne 672000, de Portet-St-Simon à Puigcerda, longue de 152km.

1. Altitude topographique

C'est peut-être la manière la plus simple de faire : je donne des coordonnées géographiques, je reçois une altitude en mètres.

J'ai monté un serveur https://www.opentopodata.org juste pour l'occasion avec les données EU-DEM de L'European Space Agency https://www.eea.europa.eu/data-and-maps/data/copernicus-land-monitoring-service-eu-dem

Opentopodata expose une API toute bête qui renvoie une altitude à partir du couple latitude/longitude ; on peut envoyer des coordonnées en batch, pour les 366000 points hectométriques du réseau ferroviaire, comptez une heure et demi sur une machine raisonnablement puissante.

Et on a un problème : on « voit » le terrain depuis le ciel, donc on voit les montagnes au dessus des tunnels, c'est ballot...

2. Altitude topographique, mais on corrige avec les tunnels

C'est assez simple : les données de la colonne précédente sont copiées, je récupère les données opendata des tunnels SNCF sur https://ressources.data.sncf.com/explore/dataset/liste-des-tunnels

Chaque tunnel possède un point kilométrique de départ et une longueur. J'arrondis volontairement au point hectométrique en dessous et j'ajoute 100m à la longueur — j'ai eu des résidu de pentes très fortes dans les tracés, ce n'est pas toujours précis.

Donc, prenons un tunnel de 1220m qui commence au point kilométrique 042+120. Il terminera raisonnablement au pk 043+340. Par conséquent, je considère une zone tunnel du pk 042+100 au pk 043+400.

Si le pk 042+100 est à 503m et le pk 043+400 à 495m, je dois descendre de 8m proportionnellement sur 1,3km. C'est le trait bleu sur le graphique, on voit bien que cela corrige le tracé dans les tunnels, quand il y a une montagne à passer.

3. Ou on utilise les déclivités en opendata

SNCF Réseau distribue aussi les déclivités en opendata https://ressources.data.sncf.com/explore/dataset/caracteristique-des-voies-et-declivite/information/ à la voie. Ce qui est un peu compliqué puisque je n'ai que les PKs à la ligne. J'ai dû ruser pour obtenir les déclivités successives à la ligne.

Ensuite, j'ai redistribué les déclivités par pas de 100m histoire de coller à mes PKs hectométriques, puis j'ai pris l'altitude du premier point de chaque ligne, altitude trouvée pendant le point 1 et j'ai appliqué les coefficients de rampes et de pente au fil des points : le trait rouge sur le schéma.

On constate des écarts notamment à haute altitude. Écarts qu'on retrouve parfois sur les lignes, mais pas systématiquement, ce qui ne permet pas de définir si l'erreur vient de mon algo ou des données sources.

Conclusion

Aucune des solutions ne s'avère parfaite mais la combinaison et la comparaison des trois est intéressante ; après tout ce qui nous intéresse c'est de savoir si on descend ou on monte plus ou moins fort, pas forcément l'altimétrie précise.

Le tablier d'une voie de chemin de fer est souvent bien plus plat et linéaire que le relief chaotique d'un massif montagneux, et la donnée source topographique ne propose qu'une précision de 25m, trop large pour une ligne ferrée qui fait 10m de large.

Une piste serait d'utiliser les données du référentiel à grande échelle RGE ALTI® de l'IGN qui propose une précision à 1m voire moins quand c'est possible/nécessaire, mais il faut traiter plusieurs dizaines de Go de données et c'est chronophage... un jour peut-être.

Enfin surtout, on peut voir que les tunnels, c'est utile :D