Mini CRs Q3 2019

23/07/2019

Historisation des données statiques :

• stocker tout nouveau fichier publié dans un répertoire
• à voir : dans un 2ème temps, tout mettre sur Github dézippé pour donner accès à l’historisation par GH

Historisation du TR pour plus tard. Aller récupérer les besoins précis des réutilisateurs

Comment on affiche les GTFS en cours, futurs, passés ?

• Mettre dans l’API tous les fichiers + les périodes de validité
• Rajouter info de l’API sur chaque page dataset : “vous pouvez récupérer tous les jdd via l’API avec cette requête”
• Sur le front : on garde comme aujourd’hui avec affichage des différentes périodes de validité et fichier en cours en haut.
• quand on aura l’historique, on rajoutera soit un lien vers le repo d’historique soit un truc déroulant pour afficher tous les fichiers historisés

Documenter la publication via ODS aussi (Béa) + contacter ODS (Tristram) pour demander validation + diffusion commune

Wikitransport - “projet Leo” :

• Noms hétérogènes pour un même point d’arrêt --> redresser les noms (“ST ROCH” --> “Saint Roch”)
• Arrêts en double entre bdd ou au sein d’une même bdd --> dédupliquer les arrêts
• Difficile de faire le lien entre un GTFS et OSM ce qui permettrait d’extraire les shapes depuis OSM par ex

Des “petits” outils à créer pour chacun de ces usages + gros travail de construction de la base de données relationnelle Identifier un premier cas d’usage concret et commencer avec Discuter avec les réutilisateurs qui font déjà ce travail de redressement pour faire ouvrir leurs règles, données redressées... Régler la question licences/CPU avec OSM Next : choisir un petit problème et le régler en mode POC, aviser ensuite Plus tard : Béa et Sabine creusent avec les réutilisateurs (pas que ?) comment ils gèrent aujourdh’ui, leurs problèmes etc.