etalab / amenagements-cyclables

Schema pour les données d'aménagements cyclables
Other
12 stars 14 forks source link

Schéma incomplet #4

Closed johanricher closed 3 years ago

johanricher commented 3 years ago

Bonjour,

Bravo pour cette initiative qui va permettre je l'espère de produire et publier d'avantage de données ouvertes et de qualité sur ce sujet !

Le schéma ne comporte actuellement qu'un seul champ pour l'identifiant PAN de l'aménagement ce qui n'est, je l'imagine bien, qu'un début. La documentation que j'ai pu trouver détaille bien d'autres champs dans une version dite "alpha", antérieure au schéma ici-présent. J'ai d'ailleurs vu celui-ci être présenté comme "beta", ce qui laisse entendre qu'il devrait être plus complet ou avancé, or il semblerait que ce soit plutôt l'inverse.

Pourquoi ne pas avoir écrit le schéma en intégrant tous les champs définis dans la version "alpha" ?

Quels sont les acteurs qui ont vocation à produire eux-même un fichier conforme à ce schéma ? Existe-t-il des fichiers déjà produits par les acteurs du domaine ?

antoine-de commented 3 years ago

Salut @johanricher désolé je suis passé complètement à coté de ton message :flushed: Tu as du regarder le repo au tout début où le schema était en cours de traduction entre le doc de travail avec la communauté et le schema technique.

Il y a maintenant tous les champs de définis dans le schema (même si il est encore officiellement en beta il me semble) et un README (encore un peu brut). @Miryad3108 pourra répondre aux dernières questions mieux que moi, mais il me semble que les collectivités françaises disposants de données d'aménagements cyclables vont produire les données dans ce format, mais à ma connaissance on n'a encore aucune données produites.

Pour info on va aussi migrer d'un schema csv à du geojson (+ des champs définis en tant que properties des features geojson) pour avoir un format plus propre (#6 )

N'hésites pas si tu as d'autres questions.

Miryad3108 commented 3 years ago

Salut @johanricher

Merci pour ton intérêt pour ce schéma.

Pour compléter la réponse d'Antoine :

N'hésites pas à revenir vers nous si tu as d'autres questions,

johanricher commented 3 years ago

Bonjour merci pour ces précisions. En effet mon message date de l'époque où le schema.json n'était pas prêt à être testé, pardonnez cette impatience. :slightly_smiling_face:

Bravo en tout cas pour toutes les avancées qui ont été faites depuis et dont je n'ai pas encore pu voir tous les aspects. Un seul élément me fait pour l'instant réagir, à chaud : le fait de passer du format de fichier csv au geojson. Concrètement cela signifie que les producteurs de données vont devoir publier les données au format JSON (lisible par une machine) plutôt que tabulaire (lisible par un humain). Au-delà de ce que ça implique en terme de complexité à l'usage pour les utilisateurs de ces données (l'open data est avant tout fait pour des humains, qui ont l'habitude d'ouvrir un fichier dans Excel), comment vont faire les producteurs pour créer le fichier ? Est-il prévu de leur proposer un outillage dédié ? Par ailleurs, une fois le fichier produit, ils ne pourront pas non plus utiliser un outil comme Validata pour vérifier et voir où sont les erreurs afin d'améliorer la qualité du fichier. Bref, c'est à mon avis un calcul dont il faut peser toutes les conséquences.

En regardant rapidement la PR, je ne vois pas d'élément nouveau qu'il ne serait pas possible de faire en Table Schema (donc pour un fichier tabulaire, csv ou xlsx). Quels sont les blocages que vous avez rencontré qui vous ont fait sortir de ce format ?

antoine-de commented 3 years ago

Bonjour @johanricher , on s'est beaucoup posé la question, la complexité vient de la géométrie qui représente l'aménagement cyclable. C'est pas forcément un point, on doit avoir une vrai géométrie et non pas juste 2 champs lon/lat. Et représenter une géométrie en csv c'est pas fou (il y a des solutions, mais on a l'impression qu'elles ont toutes leurs limites). De plus les géométries ne pourront pas vraiment être éditées via un tableur classique, donc on perd l'avantage du CSV.

Le GeoJSON nous semble assez adapté pour ce cas de figure, c'est aussi assez lisible par un humain au final (si les géométries ne sont pas trop grosses), et beaucoup d'outils les gèrent nativement.

Il me semble (@Miryad3108 n'hésites pas à me corriger si je raconte des bêtises) qu'on en a du coup demandé aux producteurs et que vu que les données vont être extraites de sig, produire du json plutot que du csv ne posait pas de soucis.

On a aussi évoqué la possibilité de faire un convertisseur CSV -> GeoJSON si on voit que c'est un besoin, mais je pense que si on va dans cette direction, il faudra sûrement un outil de saisie de données plus complexe pour renseigner la géométrie.

Ma réponse te convient ? Tu en penses quoi ?

johanricher commented 3 years ago

Il est possible avec Table Schema d'avoir un champ GeoJSON. Je suis d'accord que saisir une géométrie dans un CSV n'est pas optimal, mais pour le producteur le faire dans un JSON l'est tout autant. Il y a déjà des schémas qui ont des champs lat, long (exemple) et la production des données en CSV ne semble pas poser de problème. Je vois la géométrie dans la continuité de ça.

Pour information, l'outil CSV-GG qui s'appuie (comme Validata) sur Table Schema va prochainement être amélioré pour pouvoir saisir depuis son interface un point, et pourquoi pas une géométrie, au moyen d'un widget carto. CSV-GG va par ailleurs être rapproché de Data.gouv ce qui permettra d'y publier directement un jeu de données créé avec CSV-GG en conformité avec un schéma.

J'ai conscience que dans votre cas cela ne s'appliquera peut-être pas à la plupart des producteurs qui feront un export depuis leur SIG, c'est d'ailleurs déjà une réalité assez répandue quand on observe l'ensemble des données publiées en open data. Pour ces producteurs le format de l'output final importe peu, pour autant je pense que pour certains le fait de pouvoir créer le fichier à partir d'un tableur (ou de CSV-GG) sera appréciable.

Table Schema n'a évidemment pas vocation à couvrir tous les cas d'usages de l'open data et il n'y a donc pas de sens à le garder à tout prix. Il serait néanmoins dommage de perdre les avantages que propose ce format (surtout pour l'outillage user friendly) si ça peut être évité.

cc @abulte @geoffreyaldebert

Miryad3108 commented 3 years ago

Bonjour @johanricher

Nous avons effectivement échangé avec les producteurs avant de fixer ce format de données et avons également mené une enquête auprès des collectivités/Établissement public de coopération intercommunale ne faisant pas partie du groupe de travail afin de connaître leur niveau en SIG.

Pour l'outillage, l'association Vélo & Territoire proposera d'ici le mois prochain un outil d'aide à la saisie de ces données aux collectivités qui ne savent pas encore produire du GeoJson

johanricher commented 3 years ago

C'est entendu, merci !