Commentaires (39)

C'est le style de jeu de données qui ne peut pas être utilisé seul et qui nécessite en fonction de l'application que l'on ait à faire d'être retravaillé. Personnellement, je l'ai enregistré en format CSV. Avec ce style de jeu de données, nous sommes dans des applications mobiles a priori.

Merci pour le jeu de données. Je signale que trois stations ont des coordonnées fausses (latitude et longitude égales à 0)
Ce sont :
La Rochelle Porte Dauphine
St-Christau-Lurbe
St-Joseph-du-Castellas

Merci pour ces données.

Une remarque toutefois: Comme le dit Vincent, celles-ci sont en xls. Nous sommes donc obligés de:
1) Télécharger les données.
2) Les convertir dans un format plus "web-friendly" (xml, json,...)
3) Utiliser les données dans leur intégralité...ou les parser soi-même pour avoir l'info que l'on veut.

Plus spécifiquement, télécharger 365 kilo-octets de données, les convertir et enfin les parser pour obtenir la position d'UNE gare est une perte de ressource logicielles à long terme et ceci est dommage alors qu'une simple API répondant aux spécifications REST permettrait plus facilement de récupérer ces données.

Exemple:
GET http://data.sncf.com/api/gares/agen.xml
GET http://data.sncf.com/api/gares/agde.json
GET http://data.sncf.com/api/gares/alai/position.json
(Je laisse aux développeurs le soin d'imaginer eux-même le retour de ces appels sachant qu'il est impossible de mettre du xml ou du json en forme dans ces commentaires et que de toutes façons les non-développeurs n'y verraient que des symbôles illisibles =) ).

Dans le cas d'une API correspondant au format REST et hébergée directement par la SNCF, le bénéfice est immense: Les applications n'ont plus à télécharger une intégralité de données (statique) pour obtenir UNE info et bénéficient de réponses en temps réel (certes, cet aspect est inutile sur la position des gares, à moins qu'une moitié du territoire français subisse une "dérive" et aille faire un coucou à l'Islande...) permettant le dynamisme et la réactivité des applications utilisant ces données.

Bref, je vais tout de même convertir ces données et en faire une API REST... Juste pour le fun :D

Merci également, c'est une bonne idée.
Pourriez-vous compléter en indiquant quels sont les droits de réutilisation du fichier, la date d'actualité du fichier (par rapport au monde réel), ainsi que le système de référence de coordonnées ? (que je crois avoir deviné, mais c'est pour être sûr).

Une API serait effectivement plus adaptée qu'un fichier dans un format propriétaire publié comme pièce jointe sur une interface web, mais je pense (j'espère) que ce fichier n'est là que pour donner de la matière à nos discussions/réflexions.

Pour faciliter la ré-utilisation de ce type de données je vois à minima leur publication dans un format ouvert (XML, CSV) et éventuellement aussi via une API permettant leur interrogation (par nom, localisation).

Sur les données elles-même, l'ajout d'un identifiant unique stable sur chaque gare serait bien utile (je pense par exemple au code TR3/TT0020) voire en plus l'identifiant international dont je ne me rappelle plus le nom. Cela permettrai l'interconnexion avec d'autre sources d'information.

Une question... quelle différence par rapport aux jeux de données (plus complets) publiés en début de semaine sur data.gouv.fr ?

Désolé Christian, j'ai conscience que mon post était une évidence pour des "habitués" (formats ouverts, API, interrogation, etc...) mais ne sachant pas quel type de public se rencontrait ici pour le débat, j'ai fait le choix de faire un commentaire dont les idées seraient destinés à tous les acteurs du débat.

L'idée d'un identifiant unique pour chaque gare est intéressante, celles-ci ayant souvent des noms à rallonge voire proches ("Aix-en-Provence", "Aix-en-Provence TGV", etc...) se prêtant peu aux jeu des adresses internet. Je ne connaissais pas du tout le code TR3/TT020 mais merci de l'avoir proposé, cela m'a évité de suggérer bêtement "Un ID par ordre alphabétique"...

Pour ta dernière question, il me semble avoir lu sur d'autres pages du site que les jeux de données de la SNCF ne rentraient pas dans ceux de data.gouv.fr de par une "différenciation" de l'État et de la SNCF.

Je suis conscient de la différence entre la démarche de data.gouv.fr et celle de la SNCF, mais ma question porte sur les données elles-même.

On a un jeu disponible sur data.gouv.fr sourcé RFF/SNCF et un jeu d'exemple ici. Je ne les ai pas encore comparé mais si différences il y a, qui croire ?

La généralisation du mouvement opendata va générer ce genre de situation où pour des données en principe identiques, on va se retrouver avec plusieurs sources et sûrement pas exactement les mêmes données, d'où les questions sur les meta-données (de quand datent les data, quelle est leur précision, quelle est leur source exacte je pense en particulier à la géolocalisation provient-elle d'un géocodage, lequel, de quand date-t-il, etc).

Ces méta-données aideront à un tri nécessaire et c'est sûr qu'un fichier XLS n'est pas adapté à une standardisation ni du format des données, ni du format des méta-données.

Je pense que ce fichier d'exemple est un bon exemple de ce qu'il faut éviter (format inadapté, méta-données manquantes, manque d'identifiant unique, licence non précisée, etc). Une sorte d'opendata canada-dry ;)

À vu d'œil, je dirais qu'il s'agit du même fichier que http://www.data.gouv.fr/donnees/view/Liste-des-gares-de-v... ;)

Le problème du fichier si nous le convertissons en CSV est que la latitude et la longitude ne peuvent pas être utilisé correctement à cause de la virgule. Par ailleurs, on peut récupérer les données via dbpedia pour régler le problème.

Par définition, le CSV a le choix de son séparateur ;) Il suffit de mettre un point virgule comme séparateur et le problème est réglé :)

C'est vrai Jonathan, j'utilise toujours les valeurs par défaut. J'avais surtout fait le test pour comparer les valeurs de géolocalisation données présente aussi sur dbpedia : il y a des petites différences. Le problèmes des sources de données avait été mentionné par Christian.

Bonjour,
Pour ma part il me semble que le XML est un bon format pour ce genre d'exercice. De plus il pourrait etre accompagne d'un schema (XSD) qui permettrait de bien en comprendre la structure. Certe ce n'est pas tres revelateur sur cette exemple la mais pour d'autre jeu de donnees cela peut etre utile.

Le commentaire de Jean-Baptiste m'a fait penser à http://schema.org/ mais on a rien sur les transports...dommage =)

Bonjour a tous,

je viens de convertir ces donnees en fichier KML. Vous pouvez le visualiser sur google map: http://g.co/maps/eps6p

Une autre visualisation utilisant l'API google map est visualisable ici: http://pcreux.github.com/data-sncf-experiments/trainstati...

Et les codes sources et donnees sont disponibles sur Github: https://github.com/pcreux/data-sncf-experiments

Bref, du simple CSV ou XLS est suffisant pour diffuser les donnees statiques dans un premier temps.

Le fichier en PJ est effectivement extrait du portail data.gouv.fr, et n'a vocation dans ce forum qu'à susciter des questions/suggestions...et on peut dire que l'objectif est atteint !
Je suis d'accord que l'usage d'un ID unique serait plus propre : pourquoi pas le TR3A (propre au réseau français) ou le code UIC (international).
@Arnaud : concernant ton exemple d'API, je me demande si cela a du sens de proposer des services à granularité aussi fine pour des données de référence ? Pour moi, une API "gares" devrait renvoyer la liste complète, quitte à la stocker en mémoire dans l'application consommatrice...

@VincentD: Comme j'ai dit, pour les gares c'est pas utile (mais là encore, si la Bretagne se la joue "cataclysme catastrophe façon West Coast US" et dérive de 20km, faudra updater). Mais après pour d'autres infos, ne pas se taper un jeu entier de données pour une info (surtout pour une appli mobile), c'est un plus non négligeable.

C'est un sujet interessant. Il me semble que le debat tourne plus autour de la finalite de la démarche OpenData. Est-ce provisioner des API pour rendre accessible des donnees, ou plus simplement fournir des donnees pour alimenter des API... Pour ma part j'opterai plus pour la deuxieme version. La demarche OpenData serait plus un moyen de fournir des donnees brutes qui ensuite peuvent etre integrer a des systemes (services).

Thread effervescent en effet VincentD et bravo à Arnaud pour sa réactivité.
Concernant le code identifiant de la gare : j'avoue que le coté international du code UIC est séduisant. Quelqu'un voit il un intéret au TR3A (code de la gare sur 3 caractères)?

le code UIC me permet plus pertinent. Thalys et Eurostar vont au-delà de la France par exemple.

pourquoi se limiter a un code...? tout ce qui permet d'identifier la gare de facon unique est interessant. libre choix ensuite d'utiliser l'un ou l'autre.