Questions au sujet du tableschema de schema.data.gouv et de la réglementation de la circulation en ville

Bonjour,

Nous réfléchissons en ce moment à la création d’un schéma sur la réglementation de la circulation en ville et sa publication sur schema.data.gouv.fr

Le schéma de publication à adopter est le tableschema de frictionlessdata

Si ce modèle s’avère particulièrement riche et complet, je ne vois pas comment implémenter certains éléments, notamment quand l’objectif est la publication d’une table unique, consolidant différents éléments, et non celle de multiples tables, dans une logique de base de données relationnelle.

Pourriez-vous m’éclairer ?

  • Avec enum, on peut énumérer les valeurs d’une liste. Il me semble que la sélection doit être unique. Comment spécifier une sélection multiple ? Cela est-il autorisé dans le tableschema ? Car dupliquer des lignes qui contiendraient des éléments de géométrie de ligne risquerait d’alourdir la table ? Je m’attendrais à qqch du type [‹ Gaz Naturel ›, ‹ Electrique ›]

  • S’il est d’usage d’utiliser X ou Y, LONG ou LAT pour encoder des points, pour les géométries complexes type lignes (c’est notre cas) ou surfaces, y a-t-il une règle particulière à adopter, sans avoir recours, comme pour le GTFS, à un fichier annexe ? Est-ce le GEPAF, le WKT, ou autre chose ?

  • Pour revenir à enum, dans certains cas, des valeurs peuvent être proposées, sans pour autant être exigées. Cela se matérialise par des listes à valeurs réinitialisables et éditables, ou un champ Autre. Est-ce possible avec tableschema de créer une contrainte enum, mais qui ne soit pas une contrainte, justement ? Ou bien faut-il créer un champ de type XXX_AUTRE ? Quelles sont les conventions ?

Questions autres :

  • Généralement, on fait travailler des acteurs autour d’un standard sous la forme d’un tableur. Juste pour culture perso, existe-t-il des traducteurs csv2tableschema ou des assistants d’édition GUI ? Car l’édition du JSON est assez technique pour le quidam

  • Dans certains modèles, j’ai vu la propriété custom_checks :

    "custom_checks":[
      {
        "name":"french-siret-value",
        "params":{
          "column":"num_siret"
        }
      }
    ],
    

Je ne crois pas l’avoir vue documentée dans les specs. Permet-elle de confronter une valeur par rapport à un référentiel externalisé ? Auquel cas ce pourrait aussi être utilisé pour le code insee ? A quoi sert-elle ?

En vous remerciant par avance de vos réponses

Bonjour,
Je serais très intéressé d’échanger avec vous sur le contenu de cette base et quel type de réglementations vous souhaitez décrire dans ce schéma.

Concernant le enum effectivement je ne sais pas s’il est possible de faire des sélections multiples.
Pour les géométries, si votre fichier contient des choses plus complexes que des points, vous pouvez vous orienter vers un format geojson comme c’est le cas pour les aménagements cyclables : Schéma d'aménagements cyclables
Pour les champs « autres » qui pourraient être spécifiés, je recommanderais l’utilisation d’une seconde colonne/champ qui contiendrait ces données « valeurs si autre » pour conserver une première colonne normalisée.

Pour l’interface de visualisation, si votre schéma de données respecte le format tableschema il sera automatiquement mis en forme sur schema.data.gouv sous une forme plus lisible. Voici un exemple : Documentation de Lieux de stationnement
Enfin pour le custom check du code SIRET il s’agit simplement d’une validation de la possibilité que le code SIRET existe. Il existe des règles de création d’un code SIRET et cela a été recodé dans le « custom_check »/

Merci beaucoup pour votre réponse. Il s’agit de pouvoir numériser les arrêtés de circulation en ville : usages autorisés, véhicules autorisés,…

Ce serait avec plaisir d’échanger avec vous sur le sujet

En effet, pour ce particularisme géométrique et sélection multiple, il semble que le jsonschema soit plus approprié que tableschema

Sélection multiple, notamment :
https://json-schema.org/understanding-json-schema/reference/array.html

A priori, qqch comme ceci ?

    {
      "type": "array",
      "items": {
        "type": "string"
      },
      "enum": ["ELECTRIQUE", "GAZ NATUREL", "HYBRIDE", "HYDROGENE"]
    }

Cela dit, pour le schéma sur les aménagements cyclables, je ne vois pas de doc’ générée lisible facilement sur schema.data.gouv. Est-ce lié au jsonschema qui n’est pas pris en charge dans la génération de doc’, a contrario du tableschema ?

https://schema.data.gouv.fr/etalab/schema-amenagements-cyclables/latest.html
(pas de bouton « lire la documentation » contrairement au schéma sur les arbres, par ex.)

Tout à fait, le format jsonschema ne permet pas actuellement une visualisation sous forme de tableau pour le moment. Nous envisageons de simplifier le schema sur schema.data.gouv dans le format table pour que nous puissions avoir cette interface lisible tout en restant sur un fichier geojson.
Affaire à suivre…

Plein de questions très intéressantes et on ne peut plus d’actualité !

Des travaux ont été commencés par Etalab avec mon équipe à Jailbreak et en lien avec les mainteneurs côté Frictionless Data, justement pour améliorer l’étendue des fonctionnalités de Table Schema et des librairies associées, en particulier la librairie Frictionless, qui désormais regroupe et remplace différentes briques comme Goodtables, et qui dans sa nouvelle version 4 est bien plus puissante :

Nous avons développé Validata avec OpenDataFrance en se basant dès l’origine sur les librairies et spécifications de Frictionless Data afin d’en tirer les bénéfices tout en faisant les adaptations nécessaires pour l’open data français. Pour info, la dernière version que nous venons de sortir a fait l’objet d’un gros chantier de migration vers le nouveau framework Frictionless.

Les sélections multiples ont été implémentées à l’occasion de ces travaux récemment, du coup ce n’est pas encore bien documenté mais les explications sont assez clairement énoncées ici :

Je pense aussi que ça serait super ! En réalité, un prototype existe mais mériterait d’être finalisé. On avait envisagé de faire un véritable éditeur GUI, un peu sur le modèle de Datapackage Creator, mais on n’a malheureusement pas eu le temps de s’y mettre. Peut-être un mini chantier à envisager chez OpenDataFrance ou Etalab ?
En attendant, tu peux regarder du côté de la feature describe qui permet notamment d’inférer un schéma à partir d’un fichier exemple. Partir d’un cas concret et réel me paraît dans tous les cas une bonne pratique plutôt que d’écrire un schéma à partir d’une page blanche !

Ce n’est pas propre à la spec Table Schema mais c’est une fonctionnalité bien documentée de la librairie Frictionless qui en permet la validation. A noter que le projet Validata a depuis 2018 permis l’écriture d’un certain nombre de ces contrôles spécifiquement français. Appel aux volontaires et aux idées : réfléchissons à d’autres !

Les contraintes de type GeoJSON sont bien supportées. D’ailleurs à ce sujet, comme tu le rappelles très justement avec l’exemple du GTFS, la pratique d’intégrer des géométries dans un CSV n’a pas été inventée par Table Schema. Celle-ci n’est pas optimale mais pour les cas qui concernent des données majoritairement tabulaires ça fonctionne malgré tout très bien.

En dernier point je dirais que si Table Schema n’a évidemment pas vocation à couvrir tous les cas d’usages de l’open data puisque l’open data n’est pas fait que de données tabulaires, il a de nombreux avantages qui ne sont pas forcément repérables en amont et qui peuvent être découverts bien après leur publication. L’écosystème d’outils déjà disponibles pour les schémas, et bien sûr la communauté qui va avec, sont très appréciables et apportent une grande valeur pour les utilisateurs finaux. Je pense notamment à CSV-GG qui a de beaux jours devant lui. :slightly_smiling_face:

Je n’avais pas noté le type geojson dans le table schema. Découverte très utile. Je pense que je peux rester sur table schema, du coup. Il s’accorde mieux, je pense, à une table géographique de type geopackage.

Je pense qu’un champ autorisé de type WKT aurait été assez intéressant dans table schema, notamment car ce type de champ est assez courant dans le monde de la géomatique. En particulier, un champ WKT peut être lu et exporté depuis un outil comme QGIS. Par contre, je pense que le geojson fait encore figure d’alien dans le monde du SIG. Il y a 20 fois plus de geojson que de shp dans datagouv.

Apparemment, je peux implémenter les sélections multiples en table schema via array

Si j’implémente le type geojson et le type array dans un schéma, ce dernier sera-t-il interprété et lu correctement sur schema.data.gouv ?

Est-ce que schema.data.gouv est adapté à la diffusion de multiples tables reliées entre elles par un système relationnel, comme dans le cas du GTFS ? Sur schema.data.gouv le modèle table unique est le seul présent, j’ai l’impression.

En tout cas, merci Johan pour cette mine d’informations. Je découvre tout un monde avec frictionless

Merci aussi Nicolas

Qu’entends-tu par là ? schema.data.gouv.fr n’est qu’un catalogue de schéma. Il ne fait pas de « lecture » du schéma autrement que pour le présenter, sur la page documentation.html notamment (exemple). Cette documentation n’est qu’une traduction partielle et simpliste du schema.json sous une forme lisible par un humain et celle-ci s’appuie sur la librairie Python table-schema-to-markdown (à noter que nous avons également développé une implémentation en JS). Si ton Table Schema est conforme (et validé par la librairie frictionless-py), tu n’as rien à faire de plus.

Attention, encore une fois schema.data.gouv.fr n’est qu’un catalogue de schémas, et c’est Data.gouv.fr qui a vocation à cataloguer tes fichiers conformes à un schéma.

Quand on parle de données tabulaires* il s’agit de fichiers et non pas de bases de données relationnelles. Donc la notion de « table » n’a pas sa place dans l’open data. Même un GTFS ce ne sont que des fichiers CSV zippés ensemble.
Il ne suffit pas de faire une extraction de base de données pour faire de l’open data, et à l’inverse il ne sera jamais satisfaisant d’essayer de reproduire ce que permet une base de données relationnelle avec des fichiers CSV. Un fichier publié en open data a vocation à être lu et compris par un humain en se basant sur des connaissances universelles et indépendamment de tout contexte spécifique à un groupe ou une organisation, alors qu’une base de données est elle propre à un contexte métier, interne à une organisation.

En revanche, il y a des évolutions qui répondent peut-être en partie à ton besoin au sein des spécifications Frictionless Data, voir notamment les Foreign Keys dans Table Schema.
Mais à mon avis, cela a un sens pour des données dites « pivot » comme des identifiants officiels (code SIRET par exemple) mais pas pour lier des fichiers entre eux comme des tables d’une BDD.

Je sais qu’OpenDataFrance a une réflexion en cours qui ressemble à la tienne (voir par exemple le lien entre ce schéma et celui-ci) mais je ne suis pas convaincu de sa pertinence car cela risque de rendre très complexe la production et l’utilisation des données produites. Mais cela peut valoir la peine de tester !

* D’ailleurs, petite incise à ce sujet : « donnéees tabulaires » = fichiers CSV, TSV, avec virgule, tabulation ou point virgule, .ods et même Excel : peu importe. D’ailleurs par exemple Table Schema (et Frictionless) n’a aucune notion de séparateur, il travaille au niveau au-dessus, sur les données tabulaires et pas leur sérialisation CSV. C’est une très bonne chose pour simplifier la vie autant des producteurs que des utilisateurs des données qui n’ont plus à se préoccuper de ces questions pour eux futiles, et c’est bien ça l’objectif !

En fait, le cas est le suivant, pour lequel je me pose la question de relations. Une voie ou une partie de voie peut être soumise à plusieurs types de réglementations selon, par exemple, le type de véhicules.

Dans le modèle tabulaire, nous aurions alors ceci :

voie1,regl1,geom_voie1
voie1,regl2,geom_voie1

Dans ce cas, la géométrie de la voie est dupliquée en autant de lignes qu’il y a de règlements. Or, les champs geojson occasionnent de la lourdeur dans la table.

D’où la question de stocker dans une table la géométrie associée à chaque voie ou section de voie :

voie1,geom_voie1
voie2,geom_voie2

Cela dit, il se peut que l’on ne rencontre pas beaucoup de cas de n réglements pour une voie. Mais pour d’autres thématiques, on peut imaginer que la concentration en une seule table, et les redondances que celle-ci implique, peuvent être assez limitantes.

Merci pour toutes ces pistes : foreign key, etc…bien qu’en effet, il vaille mieux privilégier l’utilisabilité d’un fichier et d’un schéma. On préfèrera donc la création d’un seul fichier.

:+1:

L’autre approche pour rester en monotable, c’est la colonne multi-valeurs…

voie1,regl1|regl2,geom_voie1

1 Like

Dans mon cas, je prenais l’exemple de regl1 et regl2 par facilité, mais en réalité regl1 se déclinerait en de multiples colonnes qui définissent les différentes caractéristiques des autorisations ou interdictions associées à l’arrêté (type de véhicules VEH_TYPE, d’usages VEH_USAGE ou périodes horaires PERIODE_HORAIRES,…).

Certes, on pourrait, au lieu d’avoir une colonne avec geom_voie1, stocker les identifiants des voies tels qu’ils sont dans les référentiels (osm_id par exemple pour OSM) mais, d’une part, cela reste soumis à la stabilité des identifiants (risqué), d’autre part, surtout, parfois, ce sont des sous-parties de voies qui sont concernées.

A ce titre, dans le schéma sur les stationnement cyclables, un id_local et un id_osm cohabitent. Je trouve ça plutôt intéressant.
https://schema.data.gouv.fr/etalab/schema-stationnement-cyclable/latest/documentation.html#propriété-id_osm

En aparté, j’ai remarqué que la création d’identifiants id n’était pas forcément courante dans les schémas publiés sur schema.data.gouv.fr

Au final, je pense qu’on restera probablement sur de la donnée « aplatie », à moins de partir sur des foreign keys, mais je n’en suis pas convaincu car il faut privilégier la lisibilité et la réutilisabilité, d’autant plus qu’on n’aura peut-être pas autant de redondances que ça.

Ce que je me demandais, c’était si, en implémentant le type array dans mon schéma, ce dernier serait bien documenté sur la page documentation.html dans la mesure où il s’agit, je crois, d’une spéc’ assez récente de tableschema.

En tout cas, je pense avoir suffisamment d’éléments pour avancer. Aussi, je vous remercie pour les orientations que vous avez pu me donner.

Oui ça dépend en effet de la façon dont le schéma va être converti dans un format lisible par un humain (Markdown). On est en train de l’implementer dans notre librairie JS, utilisée notamment pour la doc du SCDL d’OpenDataFrance. Mais pour schema.data.gouv.fr en l’occurence c’est la librairie Python qui doit être mise à jour. A l’avenir il pourrait être souhaitable que cela soit directement géré par la librairie frictionless-py.

Merci pour la réponse

Malheureusement, l’outil python n’énumère pas les items d’Array (enum) bien que le type de champ array champ soit intégré dans le code.

Voir par ex. ce rendu où Liste est renseigné, mais sans énumération de valeurs

Le modèle de tableschema proposé par datagouv propose le champ array (mais je ne l’ai vu nulle part dans les schémas publiés sur schema.data)

J’ai vu par contre l’écriture du pattern suivant en remplacement, ici pour les types de motorisation (séparer par le caractère ‹ | ›) :

^(Électrique|Gaz Naturel pour Véhicules|Hydrogène){1}(\|(Électrique|Gaz Naturel pour Véhicules|Hydrogène))*$

J’ai questionné aujh schema.data au sujet du support du type array.

En attendant, le schéma Arrêtés Permanents de Circulation fait maintenant l’objet d’une issue sur etalab (en phase de concertation)

Et le repo a été créé avec le schema.json : GitHub - CEREMA/schema-arrete-permanent-circulation: Schéma des arrêtés permanents de circulation

N’hésitez pas à donner votre avis ! :wink: