Commentaires (33)

Du XLS ? Vous êtes sérieux ?

Tout d'abord, merci pour cette première version des fichiers de données. C'est un bon début.

En réponse au commentaire de Guillaume (http://data.sncf.com/feedbacks/88908-bugs-dans-les-donnees-de-test) :

Tiens c'est marrant, j'ai regardé les xls dans le train et je n'ai pas eu ce soucis d'espaces dans les liens sur mon téléphone...

Pour le reste, je suis d'accord avec toi et je rajouterais même :

• La colonne Ligne décrite dans la notice "équipement des gares", ne figure pas dans le xls
• Eviter d'inclure le descriptif dans les xls, comme pour celui des équipements des gares, incomplet d'ailleurs. Il y a déjà suffisamment de données à télécharger
• Redondance de données entre les 2 xls avec le code uic et le libéllé

Peut-être faudrait-il voir ces xls comme des tables d'une grande base de données.
Certaines données n'ont pas à se retrouver ensemble ou du moins pas de cette manière, comme les adresses avec les informations d'équipement et les différents libellés.
D'autres ne sont pas très explicites, comme pour les informations train / rer / tram / bus. Il manque une correspondance avec les numéros de ligne. Ici aussi on pourrait avoir un liste des trains / numéro de ligne etc avec un identifiant unique.
Enfin j'ai pas mal travaillé sur des base de données pendant mes études, pas sur des fichiers de données, donc ce sont de vieilles habitudes et peut-être ne suis-je pas dans le bon. Mais comme ça, si je veux essayer de recréer une base de données à partir de ces fichiers, ça risque d'être compliqué :)
Sinon pour parser les données, il n'y a plus qu'à se faire une bonne petite moulinette ^^

Peut-être aurais-je le temps ce week-end de faire quelques tests d'utilisation de ce format.
Je ne suis pas vraiment fan du xls non plus, mais ce n'est pas pire qu'un autre dans le sens où ça reste du parsing de chaines de caractères.

Tout d'abord, merci pour ces premiers fichiers, qui sont déjà un bon commencement ;)
Après, j'ai quelques questions : Tout d'abord pour la licence, elle semble dire tout et son contraire. « Le Réutilisateur s’engage :
• à ce que les Informations ne soient pas altérées, ni leur sens dénaturé ; »
Que doit-on en déduire ? Puis-je par exemple corriger une faute d'orthographe sur les données sans qu'elles soient considéré comme altérées ? Le pire, est que l'article 6 dit que la licence est compatible avec une CC by 2.0 par exemple. Or la licence CC by 2.0 m'autorise a faire ce que je veux des données, donc éventuellement en dénaturant leur sens par exemple, du moment que je précise bien la paternité…
Ensuite, concernant les données elle-même, mauvais point pour le xls, un csv est amplement suffisant. Dans la liste des gares, c'est dommage qu'on ait 4 appellations différentes mais aucun code TR3A par exemple.
Mais continuez comme ça, vous êtes sur la bonne voie :)

[ Article original: http://data.sncf.com/feedbacks/88908-bugs-dans-les-donnees-de-test/comments/196504 ]

Bonsoir,

Je vient de jeter un coup d'oeil aux données que la SNCF vient de mettre en ligne ! Quelques remarques en vrac:

-Il y a des espaces à la fin des noms de fichiers ("%20%20" à la fin du lien de téléchargement)
-Les colonnes du fichiers ne correspondent pas avec la notice dans le fichier des équipements
-Eviter du texte dans des champs nombres (par exemple "Passage libre" mais utiliser par exemple "-1")
-La colonne adresse n'est pas normalisée (cf. http://www.laposte.fr/sna/rubrique.php3?id_rubrique=87 ) ou ne contient parfois aucun nom de ville,parfois pas de code postal, etc...
-La colonne "Nom gare" est parfois vide
-Les champs booléens sont parfois à 1, parfois à 0 parfois vide, mais ce dernier êtat n'est pas documenté.
-Quelques petites inversions se sont glissés dans les noms. Exemple avec "Yerres" qui est sur plusieurs lignes.
-Dans le tableau des lignes, TER ne devrait-il pas être dans "Indicateur du mode" vu sa généralisation ?

Sinon pour l'instant je pense que le reste est correct. Et d'après moi il ne manque plus qu'un fichier contenant le descriptif des lignes, type "plan de réseau", qui indiquerait l'ordre des gares pour chaque ligne et/ou tronçon, et les premières applications devraient apparaître... En attendant, bravo pour ce qui a déjà été fait !

Guillaume

Bonjour à tous et merci pour ces premières remarques. Je vais tenter d'y répondre avec le concours de ceux qui ont déjà contribué à la préparation des données. Une toute première réponse concernant le xls (celle la je m'y attendais). A ce stade de la démarche, ce format ne pose de problème ni aux "geeks chevronnés", ni aux simples curieux et autres amoureux du train qui voudraient jetter un oeil et faire d'éventuelles remarques sur le fond.

@Yann : Il y a un soucis quand même à choisir du XLS, format propriétaire... arrivé là pourquoi ne pas choisir un CSV ou un format de l'Open Document ? Ensuite il y a la question réelle de la licence, comme l'indique Olivier, cette licence manque de clarté. Pourquoi ne pas choisir simplement entre ODbL ou Etalab ? On en a discuté ici et on se demande si cela a servi :)

@Sylvain : comme le dit très justement Yann, c'est encore un début, un test, une première fois... Crois moi que tout ce que vous avez pu dire est train d'être étudié. Il faut continuer à contribuer à l'OPEN DATA du groupe SNCF :)

merci pour tout !

Je ne remets pas en cause l'effort, je suis simplement surpris du côté artisanal de cette page de test quand on sait que la SNCF réfléchit au sujet depuis si longtemps. Etre positif n'empêche pas les interrogations.

Exactement.. C'est avec vos interrogations qu'on avance..

Bonjour,
Ravi de cette première mise en ligne,
Je fais confiance aux nombreux contributeurs pour apporter leurs commentaires techniques... car effectivement ça n'est qu'un début.
Bonne continuation.

+ 1 avec la remarque de @sylvain. Vivement qu'on ai à disposition un fichier CSV afin par ex d'effectuer la commande suivante (mode geek enclenché) : curl "http://www.transilien.com/web/webdav/site/transilien/shar...;

cela va nous (les data-devs) simplifier le design/développement d'applications, de services sur : mobile, tablette, web-app, télévision, web des objets, vision augmentée, etc

Le format CSV me semble en effet particulièrement adapté. Il offre un accès facile par les non développeurs via Excel, tout en étant facilement manipulable/convertible en programmation.

En revanche, pourquoi avoir choisi le système Lambert pour la localisation des gares ? Le format Latitude/Longitude me semble plus approprié pour les traitements informatiques. Le système de coordonnées géographiques Latitude / Longitude est un standard des applications de cartographie et des dispositifs de géolocalisation. (CF: la liste des gares géolocalisées, disponible sur data.gouv.fr)

Bonjour David,
Nous l'avons retenu le Lambert II parce que.... c'est celui qui est utilisé dans nos systèmes aujourd'hui. Il existe d'autres systèmes de projection dont le WGS84 qui est effectivement plus courant.

Merci pour cette réponse très franche. Des outils de conversion existent, mais je n'en ai pas encore trouvé de pratique pour traiter des coordonnées par lots.

@David: peut-être en regardant du côté de Python :) http://stackoverflow.com/questions/7157076/best-python-gi...

Voici quelques nouvelles :
1° nous avons corrigé les deux "blancs" dans les URL, Merci,
2° nous avons effectivement supprimé les descriptifs de "Ligne" dans la note explicative du fichier "gare" qui ne contient pas de colonne sur ce thème. Merci.
3° Nous allons aussi corriger quelques erreurs et essayer d'expliquer certains choix plus clairement dans les notes explicatives qui sont faites pour cela...
Donc de nouvelles versions des fichiers en perspectives !

Euh ? C'est une blague ?

Des fichiers de ce type pour faire des appli ?

Ce n'est ni fait, ni à faire....

1. Tout bon informaticien devrait savoir que l'open data se fait avec des fichiers utilisables avec des logiciels libres de droit ==> Fichier EXCEL donc il faut avoir CroSoft....

2. Des valeurs texte dans une colonne de valeur numérique

3. Format XLS inutilisable !!!! ON veut des fichiers CSV

4. C est quoi tous ces espaces dans les noms de fichiers ?

Vu la tete du fichier, on dirait qu'il a été fait par un stagiaire....

Vous etes sur que c'est un fichier réel ou c est le fichier du stagiaire et encore stagiaire de 1ere année de fac !

A se demander s'il y a des informaticiens a la SNCF..... vu le travail pondu !!!!

N'ayant pû que survoler les fichiers par manque de temps aujourd'hui, rien de plus à ajouter aux commentaires déjàs postés car le format .xls choisi et le système de coordonnées étaient les deux seuls points qui m'aient surpris, mais pour ce qui est de Lambert II étendu, il suffit d'un petit coup de PostGIS pour avoir du WGS84, donc pas d'inquiétudes; après tout, IGN aussi (si je ne confonds pas ?) fournit aussi certaines de ses données en Lambert.

En tout cas c'est un bon début :-)

Bonjour,

Merci pour ce premier fichier... je ne continuerais pas le débat sur le formar... tout du moins, cela me permet d'avoir une source pour récupérer des données fiables (je l'espère ;-) pour traiter les informations des gares dans une application. Bon, il faudra un temps de retraitement..

En première lecture, j'aurais des questions sur des données complémentaires dont je pourrais avoir besoin :

• horaires des trains
• tarif des différents trajets possibles
• trains en retards

Avez-vous défini un planning quand à la disposition des différentes données pour les trains en région parisienne ou en province (ou je me situe)?

Personnellement adepte des architectures à bases de services, planifiez-vous également de tels déploiements?

Comme tout le monde je suis pas mal déçu...
Tous les débats sur les questions juridiques et techniques ont indiqué une nette demande de la communauté :

• pour les formats, à minima du CSV, et au mieux du RDF, mais pas du XLS....
• pour la licence, adopter l'existant, c'est à dire EtaLab ou ODbL, mais ne pas ajouter à la complexité en proposant encore un nouveau texte différent. On ne se prétend pas compatible sans vérifier certaines conditions, les conditions de non-altération/dénaturation évoquées ainsi que la clause laissant au producteur le droit de modifier les conditions de réutilisation rendent ce texte tout sauf compatible OpenData.

J'ai du mal à concevoir qu'un juriste puisse envisager d'ajouter une telle clause dans un contrat (article 3 alinéa 4) : "alors je vous propose de signer un accord, dont je peux unilatéralement changer les termes quand cela me chante et sans que vous ayez rien à dire, vous signez ?" mmmmm.....