Open NicolasBerthelot opened 3 years ago
fredpetit
commented
3 years ago En tant que producteur de données, cette modification a un impact sur l'homogénéité du système. Il faut donc que cela soit partagé en amont (notamment pour les schémas déjà produits) pour assurer de manière continue la qualité des données. Personnellement, pas d'avis sur un modèle ou l'autre, avec le risque cependant pour certains producteurs de mettre du temps à faire les évolutions. @geoffreyaldebert
johanricher
commented
3 years ago Je suis tout à fait d'accord avec toi @NicolasBerthelot, étant donné que le type geopoint n'apporte que des avantages, tous les schémas ont vocation à évoluer pour en bénéficier. Je vais également pousser OpenDataFrance dans ce sens pour les schémas du SCDL.
Cela entrainera un changement cassant pour les schémas concernés mais si ceux-ci on respecté les conventions SemVer et notamment le fait de ne pas publier une version 1.0.0 avant de laisser passer une longue période de test / stabilisation, cela ne devrait pas poser de problème. Dans le cas contraire, ces schémas devront subir la release d'une version 2.0.0 voire 3.0.0 pas forcément compréhensible par les réutilisateurs...
thbar
commented
2 years ago Hello! @Miryad3108 et moi (et d'autres) travaillons sur un nouveau schéma CSV (schéma de comptage des mobilités, avec 3 fichiers).
@NicolasBerthelot a remonté le fait que nous avions pour l'instant opté naturellement (car c'est ce qui parlait le plus à l'audience de producteurs et de réutilisateurs qui étaient présents à nos ateliers de co-design du schéma) pour un stockage sur 2 colonnes (latitude et longitude), et nous a prévenu de la présente discussion.
De notre côté, par rapport à l'audience qui est la notre sur ce schéma, nous avons opté pour une simplification, le plus possible, de la production et de la consommation des données.
Dans ce contexte, 2 colonnes séparées sont bien plus simples à gérer (pas de problème d'encodage de guillemets autour, ou d'escaping de virgule ou autres sujets similaires et très courants).
Pouvez-vous nous éclairer sur les avantages concrets (vous indiquez qu'il en existe de nombreux, mais on manque d'exemple ne connaissant pas bien ce point précis) en terme de capacités apportées (autre que la validation TableSchema) ?
À l'inverse j'indiquerai que un format tel que "[2,40]" nécessite, si l'outil en cible ne supporte pas GeoPoint, un pre-processing qui n'est pas trivial pour tout le monde (ou qui en tout cas va embêter du monde).
Merci pour vos réponses ; avec ces éléments, nous pourrons allons sonder nos "auditeurs" et voir ce qui paraît faisable !
johanricher
commented
2 years ago À l'inverse j'indiquerai que un format tel que "[2,40]" nécessite, si l'outil en cible ne supporte pas GeoPoint, un pre-processing qui n'est pas trivial pour tout le monde (ou qui en tout cas va embêter du monde).
Ce format array n'est pas obligatoire avec le type geopoint, par défaut c'est simplement une string “lon, lat" comme documenté ici : https://specs.frictionlessdata.io/table-schema/#geopoint
Contrairement au schéma schema-stationstaxi qui a le geopoint par défaut, le schéma schema-irve a un geopoint au format array mais je ne connais pas la raison de ce choix. @geoffreyaldebert ?
Avantages :
geopoint peut être vérifiée nativement par le validateurgeopoint (cf. screenshot ci-dessous).
Dans ce contexte, 2 colonnes séparées sont bien plus simples à gérer (pas de problème d'encodage de guillemets autour, ou d'escaping de virgule ou autres sujets similaires et très courants).
Pour une saisie à la main : dans un outil tableur comme Excel, avec le format par défaut, il n'y a pas de complexité supplémentaire pour l'utilisateur entre une seule colonne ou deux colonnes (l'ajout de guillemets n'est pas nécessaire).
Pour une production automatisée ou agrégée, à condition que le champ soit valide (cf. mon point ci-dessus), je ne vois pas de problème en plus ou en moins par rapport à deux colonnes distinctes.
Quels seraient les inconvénients et dans quel contexte de production ou réutilisation des données se manifesteraient-ils ?
fredpetit
commented
2 years ago Bonjour @johanricher , je viens de découvrir à cette lecture que le schema irve intègre maintenant le geopoint. c'est un peu hors-sujet, mais comme nous avons très tôt publié les données selon les schémas proposés, nous n'avons pas vu ces évolutions. Au-delà du fait que nous allons reporter la modif dans nos données, comment peut-on être averti des évolutions des schémas ?
Car en fonction de ce qui va être arbitré sur {Xlon, Ylat} vs {geopoint}, il faut vraiment que cela soit homogène pour l'ensemble des schémas. Et quel délai se laisse t'on pour cela ?
Une conséquence est que les données ne soient plus consolidées pour la base nationale, car plus en adéquation avec les format.
En ce qui concerne ta dernière question, sur les inconvénients de production, de ntore côté, il n'y en pas plus que cela. Cependant, nous avons la chance de maîtriser nos dévs en interne à la collectivité, ce qui est loin d'être le cas de l'ensemble des producteurs. Avant d'atteindre une homogénéité au niveau national, avoir des formats concurrents risque d'^tre contre-productif.
Je note cependant que ce format me semble "techniquement" plus pertinent, ce qui est moins évident "fonctionnellement".
johanricher
commented
2 years ago comment peut-on être averti des évolutions des schémas ?
Par exemple en s'inscrivant aux notifications des releases sur le dépôt Github/Gitlab du schéma.
Car en fonction de ce qui va être arbitré sur {Xlon, Ylat} vs {geopoint}, il faut vraiment que cela soit homogène pour l'ensemble des schémas.
Par conséquent il faut considérer chaque schéma comme ayant son existence propre et ses évolutions indépendamment des autres.
Et encore une fois les pratiques SemVer (laisser passer une longue période avant de publier une version 1.0 qui doit par définition être stable) apportent une partie des réponses à tes remarques. Dans ce cas de figure, avant une version 1.0, les producteurs de données peuvent et doivent s'attendre à ce que le schéma évolue et casse leurs process. Il faut considérer ces producteurs comme des "early adopters" qui vont essuyer les platres et permettre de détecter des problèmes dans le schéma et donc de l'améliorer.
Une version 1.0 doit être publiée quand le schéma est considéré par ses premiers utilisateurs comme "stable". C'est un débat plus large mais pour ma part je préconiserais d'établir un critère objectivable pour déterminer quand l'adoption d'un schéma a atteint un seuil critique. On pourrait par exemple définir le seuil à un nombre de jeux de données publiés sur data.gouv.fr, puisqu'il est désormais possible de chercher un jeu de données par son schéma :
Il sera sans doute possible prochainement d'aller plus encore et de faire une recherche par schéma et obtenir les jeux de données conformes à ce schéma. Ca me paraît le meilleur critère pour déterminer l'adoption d'un schéma.
fredpetit
commented
2 years ago L'homogénéité entre les schémas ne pourra jamais exister à 100 %.
Certes, mais ce n'est pas pour autant qu'il ne faut pas harmoniser
Cela n'est ni possible ni d'ailleurs souhaitable.
Là, je ne suis pas d'accord. Si tu veux perdre la capacité à produire des données, à les maintenir, et de fait à garder un niveau de qualité suffisant, c'est le bon moyen. De mon expérience, on voit que les collectivités (au sens large) ont déjà du mal à sortir des données, alors les mettre à jour, cela repose souvent sur des actions one-shot, ou sur du bon vouloir.
Dès qu'on met cela en parallèle de l'harmonisation des SI, sauf à avoir une DSI hyper-opérationnelle et hyper-outillée, on est loin du compte et d'un impact négligeable.
Il me parait souhaitable que, au même titre que des schémas sont définis, proposés et validés par un certain nombre d'acteurs et qu'on demande à tendre vers ceux-ci, qu'il en soit de même pour les formats. C'est p-e un voeu pieu, et qui est probablement long à mettre en place, mais cela me semble légitime.
johanricher
commented
2 years ago Pour que je comprenne la proposition, en pratique (ou avec un exemple concret) cela se passerait comment ?
fredpetit
commented
2 years ago cad ? (j'ai du mal comprendre le sens de ta question) le but est simplement d'envisager quel est le format cible pour l'ensemble des schémas (sur la partie localisation) pour ne pas avoir n convertisseurs de données avant publication. histoire de se (nous) simplifier un peu le travail ;-)
johanricher
commented
2 years ago D'accord pour "envisager" et pourquoi pas rédiger des bonnes pratiques mais ma question c'est : au-delà comment réaliser ce que tu proposes ? C'est à dire en pratique :
thbar
commented
6 months ago Ce sujet est revenu sur la table (on en a parlé pas plus tard qu'aujourd'hui avec @jmaupetit de la startup Qualicharge) et je vois que j'ai oublié de répondre à cette question:
Quels seraient les inconvénients et dans quel contexte de production ou réutilisation des données se manifesteraient-ils ?
Quand un utilisateur s'appuie sur un outil qui n'a pas une connaissance native de ce format GeoPoint, il est nécessaire de faire du pré-processing, de parser/interpréter, etc. Je prends au hasard n'importe quel outil de BDD capable de taper sur des fichiers plats, on ne va pas pouvoir directement exploiter le fichier, il faut pré-traiter. Je trouve ça vraiment dommage en pratique à la réflexion (avec quelques années de recul suite au début de cette discussion!).
thbar
commented
6 months ago Je rebondis sur d'autres points :
pour le schéma IRVE, on s'appuie sur TableSchema car c'est pratique, mais le format GeoPoint (https://specs.frictionlessdata.io/table-schema/#types-and-formats) reste par ailleurs quelque chose de très spécifique Frictionless: quand on demande aux gens de fournir de la donnée dans le cas IRVE, ils pensent CSV, pas Frictionless. Avoir une colonne avec un escaping de "," et deux valeurs dedans n'est pas très naturel pour grand monde côté production là dessus. Un validateur pourrait savoir valider des colonnes en X et Y séparé tout autant, on pourrait aussi exprimer les mêmes contraintes que dans le schéma IRVE par d'autres moyens techniques que Frictionless.
pour le respect des schémas (voir https://github.com/datagouv/schema.data.gouv.fr/issues/191#issuecomment-934301009), côté IRVE c'est "assez simple" : un mélange de juridique, de "lobbying pratico-pratique" (si vous n'êtes pas dans le format, vous ne serez pas dans la consolidation nationale etc), d'amendes et de subventions conditionnées au respect du schéma, par exemple, sont largement suffisants pour faire respecter la chose. Par ailleurs, les producteurs (IRVE dans ce cas) ont un gros intérêt à ce que leur donnée soient diffusée, donc ce qui fait que ça marche, c'est l'alignement des intérêts de part et d'autre.
johanricher
commented
6 months ago Quand un utilisateur s'appuie sur un outil
Tu parles d'un utilisateur qui produit un fichier conforme à un schéma ? quel schéma, et à l'aide de quel outil dans ce scénario ?
Si on parle d'Excel ou tout autre outil de saisie "à la main"* par exemple, mon avis est toujours le même :
Pour une saisie à la main : dans un outil tableur comme Excel, avec le format par défaut, il n'y a pas de complexité supplémentaire pour l'utilisateur entre une seule colonne ou deux colonnes (l'ajout de guillemets n'est pas nécessaire).
Donc geopoint ou pas dans ce scénario en l'état actuel de ma compréhension des usages des producteurs, c'est iso du point de vue user.
* Ce qui encore une fois n'est pas le scénario que je privilégie, puisque publier.etalab.studio (dont est issue la grande majorité des fichiers IRVE) et d'autres UI existent et sont utilisés, ce sont autant d'arguments en faveur du geopoint.
En pratique, en l'état actuel des choses, pour IRVE, mettre les coordonnées géo au format geopoint a fait gagner du temps et limité les erreurs car les producteurs utilisent publier.etalab.studio et qu'il propose un widget d'aide à la saisie avec geopoint. Pour d'autres schémas, si cet outil est utilisé (et même avec Excel), je pense que l'argument est le même.
thbar
commented
6 months ago Hello @johanricher !
Tu parles d'un utilisateur qui produit un fichier conforme à un schéma ? quel schéma, et à l'aide de quel outil dans ce scénario ?
Je parle d'un "ré-utilisateur" plus technique qui va vouloir ingérer la donnée, la mettre dans un outil d'analyse ou un système à lui.
Dans ce cas pour en avoir parlé avec plusieurs personnes, le fait de tomber sur un CSV qui contient (je cite) une "sorte de mini-CSV mais sur une colonne à l'intérieur" est tout à fait surprenant quand on ne connaît pas ça préalablement.
En pratique, en l'état actuel des choses, pour IRVE, mettre les coordonnées géo au format geopoint a fait gagner du temps et limité les erreurs car les producteurs utilisent publier.etalab.studio et qu'il propose un widget d'aide à la saisie avec geopoint.
Alors sur ce point je suis bien d'accord: ce choix de format est poussé car il nous (en tant que plate-forme d'état) facilite la vie pour le déploiement des outils de validation, car ils fonctionnent justement avec Frictionless, si j'ai bien compris.
Ce point est bien clair, et ça apporte une plus-value à nous (en tant que fournisseurs d'outils) et donc indirectement aux utilisateurs qui s'appuient dessus.
Mais si nos outils de validation savaient valider avec un X et Y en deux colonnes, ça leur irait tout aussi bien, et peut-être que Frictionless pourrait permettre d'exprimer exactement ça ? Si ce n'est pas le cas je suis bien tenté d'aller ouvrir un ticket là bas.
Le souci que j'y vois au final, c'est qu'on part d'une spécification "CSV basique" et qu'au final, quelque part, le "détail d'implémentation de la validation du GeoPoint" (un gros détail certes) finit par "leaker" dans le format lui-même, et ça rend côté réutilisateur (une fois de plus, uniquement sur la base des échanges que j'ai pu avoir) l'expérience de consommation de la donnée un peu surprenante et un tout petit peu plus error-prone (il faut "re-parser" la colonne).
A la réflexion (et je ne juge personne je précise :smile:) il y a une balance qui a été faite là dessus entre "la fonctionnalité de validation qu'on peut apporter et l'appui sur frictionless" d'une part, et la facilité de consommation d'autre part.
Je serais beaucoup plus à l'aise si on arrivait à conserver des colonnes séparées aujourd'hui (j'ai mis du temps à mûrir ma réflexion), et peut-être que je trouverais ça cool que frictionless évolue dans ce sens, pour que sémantiquement ça soit considéré comme un blob.
Désolé si j'ai pu faire quelques "raccourcis" (je ne suis pas un énorme connaisseur de frictionless, validata ou "publier"), et ça fait un peu pavé, mes excuses pour ça !!!
(plutôt fan pour en reparler de vive voix à un moment avec ceux que ça tente)
Dans les schémas récents (https://github.com/etalab/schema-irve ou https://github.com/openmaraude/schema-stationstaxi) les coordonnées géographique d'un point sont exprimés dans un seul champ appelé geopoint ou coordonneesxy. Cela a pour avantage d'être associé à un type standardisé par le format TableSchema. Tout un panel d'outils et de validateurs sont permis par ce modèle. L'ancien système en deux champs xlong ylat semble donc caduque.
Or, plusieurs schémas de données utilisent encore ce format (https://github.com/etalab/schema-stationnement-cyclable ou https://github.com/etalab/schema-stationnement). Est-ce qu'il est temps de lancer une vague d'homogénéisation des schémas de données pour converger vers la solution GeoPoint ?
Il semble important que nous ayons une stratégie claire sur ce sujet pour homogénéiser nos pratiques.