J’ai trouvé un fichier de licence 0dbl (voir là) contenant la totalité des points kilométriques du réseau ferré français.
Je voulais vous demander si au vu de la licence c’est possible de les importer.
Les points viennent de l’opendata de la sncf, et sont tout les cent mètres. Aujourd’hui, j’ai fait une requète overpass qui m’a permit de constater que les pk ferroviaires ne sont vraiment mis que sur le projet de LGV Bordeaux-Toulouse (et donc pas dans le file). Il y en a également sur la LGV SEA mais seulement tout les kilomètres, et quelques autres disséminé sur le territoire.
Je voudrais votre accord pour tous les importer, ce qui présente deux défaut :
Les points actuels restent
Les points ajoutés ne sont pas parties des voies, mais juste à côté.
-Pour ce premier, je me demande si ça ne demanderait pas moins de travail de supprimer les existants pour les remplacer par le fichier, qui est très complet et précis, plutôt que d’essayer de repérer quel pk est déjà sur la map, afin de ne pas l’importer une seconde fois.
-Pour le second problème, il « suffira » de les placer un à un, mais cela reste avantageux d’importer les points car il n’y a pas besoins d’ajouter un à un chaque point à la bonne position, restant juste la manip de potentiellement les copier afin de les mettre sur chaque track.
Pour ce qui est des tags, dans le fichier ils sont :
code_ligne=xxxxxx
pk=xx.x
unit=hm
Sur OSM ils doivent être :
railway=milestone
railway:position=xx.x
La transition est simple et rapide à effectuer avec JOSM.
Je peux volontiers m’occuper de cet import, mon ordi est suffisamment puissant.
Sur la licence, à partir du moment où c’est odbl ou LO, y a aucun problème.
C’était plus pour voir l’opportunité d’import (intégration), la qualité des données et ce que Denis a déjà fait sur le sujet et qui pourrait t’aiguiller.
Le problème ne vient pas de la licence en effet mais plus de la qualité des données. Ce que dit Nicolas dans sa réponse c’est que le pk c’est pas juste bêtement des points que l’on peut calculer de manière automatique. Il y a des trous, des erreurs qui sont documentées dans notre SI mais qui n’ont pas été mis en opendata (faudra que je le signale au responsable).
J’ai en effet repris les tracés des voies du RFN (90% actuellement). A priori (hors tunnels), le tracé est de meilleur qualité. Cela pourra donc servir de future base à une couche de pk.
Dans l’intervalle, je me hâterai de ne rien faire avec ces données. En revanche, renseigner les pk des différents objets, en particulier les passages à niveau, avec railway:position:exact est déjà une vrai plus.
Pour le moment ne n’ai plus trop de ressource pour travailler sur le sujet. Cet été probablement.
Ce qu’il est important de comprendre c’est que les pk (qu’ils soient issus de l’interne ou recréés à l’extérieur de la SNCF) ne seront jamais les localisations des panneaux présents sur le terrain (repères kilométriques et repères hectométriques). Cela n’a pas été prévu et sera impossible en dehors de la SNCF (et donc ne se fera pas).
Au mieux, on aura des interpolations dépendantes de la précision du tracé des voies.
Donc, dans ce cas, on peut les importer, car on n’aura pas mieux mais c’est une bonne base pour tous ?
Car comme tu le dit @dh67 les panneaux sont présents sur le terrain, ce qui signifie que la carte, si elle a une précision à deux ou trois mètres, est tout de même suffisamment précise (je trouve, mais après je n’ai jamais fais de travaux sur les voies ).
J’ai peur qu’on parle de précision décamétrique, au mieux.
Mais pourquoi pas après tout. Si quelqu’un (toi ?) a envie de recaler les pk issus des calculs de Nicolas sur les tracés actuels OSM (voie 1 ou voie 2 ?), j’observerai cela en spectateur.
Un 1er exercice intéressant à faire est de comparer la distance théorique entre 2 passages à niveau pourvu d’un railway:position:exact (Grand Est est un bon terrain de chasse vu que c’est complet et conforme) et la mesure réelle entre les deux points (le long de la ligne).
Les PN sont les seuls endroits ferroviaires (avec les pont-route et les gares) où l’on peut s’approcher au plus près de la réalité du réseau ferroviaire.
Justement !
C’est en comparant les PK de ce genre de lieux avec ceux du fichier que j’en ai conclu que c’était une base de données relativement précise et fiable (relativement car je n’ai évidement pas recalculé chacun des 360 000 points du fichiers ). Je suis aussi partit du principe que si c’est des données SNCF, c’est qu’elles sont suffisamment précises pour qu’elle même les utilise (CQFD).
Beaucoup de données opendata n’ont pas la qualité qu’on imagine. Il faut les confronter au terrain pour véritablement juger leur qualité, et assez souvent on a de bien mauvaises surprises !
Je confirme ce que dit Christian. Il n’y avait qu’à voir les tracé des lignes LGV, propres chez OSM et découpée à la hache côté SNCF. Il y a parfois 50 m d’écart entre leur tracé et l’emplacement de la voie.
OK,
Donc, si, ligne par ligne, je vérifie la correspondance des points avec les passages à niveaux et autres, et que ça correspond ou que j’ai corrigé, je peux les importer ?
En gros si je me sert du fichier comme base uniquement, avec un contrôle total et précis des distances, là c’est bon ?
Il faut vérifier la cohérence avec les infos de PK déjà présentes dans OSM, issues en principe de relevés de terrain.
Pour ça qu’on ne parle pas d’import mais d’intégration, c’est à dire vérifier la cohérence avec l’existant, reporter sur les objets déjà présents les nouvelles infos, etc.
En général, ça nécessite une bonne passe manuelle, avec une dose d’automatisme.
Si tu trouves des pk issus du terrain, ça m’intéresse… Pour mémoire, les emprises ferroviaires (sur lesquelles se trouvent les RK (repères kilométriques) et les RH (repères hectométriques) sont interdites au grand public sauf autorisation et accompagnement par du personnel habilité.
Se promener sur les emprises ferroviaires est non seulement interdit, passible d’une forte amende (3700 euros de mémoire) mais surtout très dangereux.
Sinon d’accord avec l’intégration
Bonsoir Christian, te souviens-tu, je t’avais parlé des PR (points repères) non « kilométriques » des RD (départementales) du Finistère où ils figurent tous (ayant été relevés au gps par moi-même et mon collègue) dans le jeu de données de l’opendata29. Je repose donc la question concernant l’opportunité de les intégrer ou non. Kenav’henta.
Aucun problème pour ajouter les PR des routes dans OSM, j’en ajoute parfois quand les marques sont visibles sur les orthos. C’est aussi présent dans le rendu de la BDTopo.
).