Vers un TableSchema geofriendly ?
Initié par le groupe frictionless, adopté par schema.data.gouv.fr, TableSchema est de fait un peu le “standard des standards” pour les données ouvertes en France.
Un schéma TableSchema prend la forme d’un fichier JSON définissant, entre autres, la liste des champs, leurs noms, mais aussi les rangées de valeurs numériques, les listes de valeurs littérales possibles.
Dans TableSchema, un champ avec liste restreinte de valeurs s’écrit comme ceci :
{
"name":"classification",
"description":"Classification de l'objet.",
"example":"Classification A",
"type":"array",
"arrayItem":{
"type": "string",
"constraints": {
"enum": ["Classification A", "Classification B", "Classification C"]
}
}
}Cet extrait est issu du schéma proposé par Etalab
Ce schéma au format JSON peut servir, d’une part à contrôler les données afin de veiller à ce qu’elles respectent des spécifications (voir à ce titre les outils validata d’OpenDataFrance et validate de frictionless), mais aussi, ce qui est original, à produire des masques de saisie obéissant aux règles définies dans le schéma (voir l’outil CSV-GG).
Pour contrôler une donnée avec la suite frictionless, on procède comme suit :
frictionless validate --schema schema.json data.csv
Un schéma JSON TableSchema peut constituer une pièce utile dans un cahier des charges visant la production de données normalisées.
Des lacunes pour le côté spatial
TableSchema est assez complet pour ce qui est du contrôle de valeurs numériques, alpha-numériques et temporelles, mais révèle selon moi beaucoup de lacunes pour ce qui est de la partie géographique de données à composante spatiale.
Dans TableSchema, la spatialité d’un champ est envisagée de deux façons. On peut la spécifier via un type de champ appelé geopoint (pour les points), ou un champ geojson (pour tous les types géométriques, que ce soit point, ligne ou surface).
Dans l’outil en ligne publier.etalab.studio, le simple fait de mentionner le type geopoint pour un champ permet de bénéficier d’une fenêtre cartographique dans le formulaire où saisir le point.
Prenons par exemple le schéma sur les stations de taxi avec un champ nommé geopoint et de type geopoint. Nous avons ce rendu dans le formulaire :
Passons aux écueils formulables à l’encontre de la version actuelle de TableSchema.
Du geojson peu adapté pour une lecture en tableau
TableSchema est conçu initialement pour un format de données tabulaire.
Pour les formats de données arborescents et spatiaux, c’est davantage JSON Schema qui est conseillé, mais cela impose de produire la donnée source au format geojson.
TableSchema envisage d’inclure l’information géographique “complexe” au format geojson. Mais personnellement, je trouve que le geojson se lit difficilement dans la cellule d’un tableau, contrairement au WKT.
Cette hybridation tableau-arbo, qui peut paraître originale et intéressante à première vue, me semble assez peu pertinente au final, notamment en terme de lisibilité.
Le WGS84, passage obligé ?
Le geojson, par essence doit être en WGS84. Certes, rien n’oblige de fournir un fichier geojson dans ce système, mais ne pas le faire peut être source de confusion.
Le RFC de geojson expose en effet ceci à la section 4 :
The coordinate reference system for all GeoJSON coordinates is a geographic coordinate reference system, using the World Geodetic System 1984 WGS 84 datum, with longitude and latitude units of decimal degrees.
Certains regrettent l’omniprésence du WGS84, notamment chez les utilisateurs hexagonaux car ce n’est pas sans effet sur la gouvernance, ou la précision de la donnée. Il est difficile de l’imposer aux jeux de données nationaux, d’autant plus que le RGF93 est requis pour le territoire métropolitain.
Voir à ce titre les réactions à un tweet de Boris Mericksay sur twitter, à propos du jeu de données des aires de covoiturage :
Un besoin de géographie remonté par des utilisateurs
Dans les issues de frictionless, plusieurs besoins relatifs à la dimension géographique sont remontés.
Il y a cette issue intitulée Geo “profile” for Data Package et cette autre intitulée Develop Geo data specification protocol
Les spécifications concernant la géométrie sont en effet actuellement inexistantes dans TableSchema quand il serait utile de mentionner le type géométrique, la surface minimale d’objets, l’étendue géographique, autant d’éléments nécessaires à la qualification de la donnée géographique.
Ce qui n’a pas été pensé dans les schémas ne peut être spécifié. Ce qui n’est pas spécifié ne peut être qualifié. Ce qui ne peut être qualifié peut se trouver de mauvaise qualité. Ce qui est de mauvaise qualité peut avoir un impact sur la qualité des décisions prises et donc sur les citoyens.
Nous voyons donc que de fil en aiguille, la conception des schémas peut impacter la qualité de jeux de données.
La qualification de données spatiales n’est pas une mince affaire puisqu’elle demande de considérer des composantes d’une assez grande complexité, telles que la position, la forme et la relation d’objets dans l’espace.
Malgré tout, certaines composantes restent assez simples à vérifier, telles que l’étendue des objets (suis-je bien dans la zone de référence ?), la surface ou la longueur minimale des objets (mon objet est-il trop petit ?).
Une solution serait d’améliorer TableSchema, une autre de créer une norme en complément pour la partie géographique. Cette dernière option n’est selon moi pas recommandable, puisqu’elle nous éloigne du ‘commun’, et introduit une nouvelle multitude, source d’ambigüités.
Passons aux propositions.
I ❤ CSV & WKT
Si geopoint et geojson sont les deux seuls types géographiques dans TableSchema, TableSchema aurait selon moi tout mérite à intégrer le WKT comme troisième format officiel de champ pour la géométrie : à quand une section https://specs.frictionlessdata.io//table-schema/#wkt ?
A quoi ressemble un fichier CSV avec de la géométrie, aka un GeoCSV ?
Voici un exemple de fichier GeoCSV :
La géométrie, dans le fichier ci-dessus est encodée en Well-Known-Text dans une colonne _geom.
Le WKT me semble beaucoup plus dans la culture des services SIG que le geojson, notamment dans les Collectivités. Il se lit confortablement au sein d’un tableau.
Même si un standard doit être établi en dehors de toute considération logicielle ou d’usage trop spécifique, il est utile de mentionner que le GeoCSV est pris en compte nativement dans QGIS via la fonction Ajouter un champ de texte délimité.
Aussi, le projet frictionless-geojson, initié lors d’un hackathon de frictionless, a pour objet de gérer le WKT d’un tableau CSV (ou GeoCSV) de façon à en assurer la conversion en geojson. frictionless-geojson gère d’ailleurs aussi la conversion geojson vers CSV.
Le besoin d’implémentation du format WKT dans TableSchema semble partagé.
Proposition de spécifications géos dans TableSchema
Face à l’absence de spécifications sur la géo, j’ai proposé dans le groupe discord de frictionless une implémentation géo dans TableSchema via une initiative appelée geo4TableSchema.
geo4TableSchema se propose d’ajouter le format wkt et de formuler des spécifications pour la géographie.
S’agissant des spécifications, il s’agit par exemple de pouvoir définir :
- l’étendue relative aux objets de la table : bounds
- le type géométrique : geomtype
- l’unicité : unique
- le système de projection : crs
- la possibilité ou non de recouvrement : overlaps
- la surface minimale d’objets : minArea
- la longueur minimale de segments : minLength
Voici comment un champ géométrique WKT, appelé _geom, pourrait être spécifié, avec ses définitions et ses contraintes, dans un schéma JSON TableSchema :
{
"name":"_geom",
"title":"Polygon geometry",
"description":"Polygon geometry",
"type":"wkt",
"geomtype":"polygon",
"crs":"EPSG:4326",
"horizontalAccuracy":5,
"constraints":{
"required":true,
"unique":true,
"overlaps":false,
"minArea":100000000,
"bounds":[
4.9283,
43.0756,
7.6412,
45.0923
]
}
}En plus de cette formalisation, j’ai conçu une petite preuve de concept appelée geovalidate (écrite en python), qui permet de contrôler les données géographiques selon le standard.
Soit le fichier suivant :
Le contrôle se fait comme ceci :
python geovalidate.py invalid-polygon.csv schema-polygon.jsonet produit le rapport de vérification suivant :
File : invalid-polygon.csv
Geometry column : '_geom' is the geometry column according to the schema
Analyzing '_geom' column...
[Warning] 2 rows without geometries were found : 9, 10.
0 : overlaps 1
0 : overlaps 2
1 : equals 2
1 : overlaps 0
2 : equals 1
2 : overlaps 0
4 : ymin too low. ymin (42.736835) is inferior to ymin bounds (43.075600)
6 : geometry is not valid
7 : area too small. It is smaller than 100000000 square meters
8 : geometry is not valid
9 : no geometry
10 : no geometryL’invalidité géométrique (soit la présence d’auto-intersections) est aussi contrôlée.
Autres projets
Mentionnons quand même d’autres initiatives autour des spécifications géographiques dans les données.
QompliGIS
Le projet QompliGIS d’Oslandia intègre lui aussi des routines de contrôle, mais selon une formalisation qui lui est propre, en YAML.
Interlis
J’ai aussi fait connaissance d’une norme suisse qui semble très complète, appelée Interlis.
spatial-data-package
Enfin, cividi, qui a produit frictionless-geojson s’est intéressée à la description de mapviews ou vues cartographiques dans les Data Packages via un projet appelé spatial-data-package
Converger
Je pense qu’il y aurait tout mérite à ce que tous ces projets convergent vers un standard des standards qui leur soit commun.
Espérons que les doléances de la communauté géomatique (aka #gistribe), concernant le défaut de dimension spatiale dans les schémas, soient prises en considération dans les spécifications, puisque cela impactera la qualité des contrôles et donc, en cascade, celle de nos opengeodata.
