-
Notifications
You must be signed in to change notification settings - Fork 1
Open
Description
Contexte
- DescribeFeatureType fournit uniquement un nom technique et un type pour décrire les propriétés des tables
- OGC API - Features - Part 5: Schemas devrait améliorer ce point avec "title", "abstract", queryables, "examples",...
- Toutefois, GeoServer, pg_featureserv & co ne seront pas capables de deviner le schéma des données
Impact
- Un humain doit aller fouiller dans les spécifications pour comprendre à quoi sert à quoi sert une propriété
- Un LLM peut halluciner ou avoir du mal comprendre le rôle d'une propriété
Actions
- Générer des schémas pour les tables (ex : BDTOPO_V3/batiment.json) à partir de la base de données utilisées pour générer la documentation BDTOPO explorer
Dans l'idéal, il faudrait publier ces schémas sous forme d'un dépôt github et le référencer au niveau de https://schema.data.gouv.fr/ + éventuellement sous forme d'annexe au niveau de l'entrepôt GPF. Pour les premiers tests, il est possible d'en générer quelques un avec un LLM (DescribeFeatureType + page de doc / PDF --> schéma JSON)
- Si un tel schéma existe, le renvoyer à la place de la réponse de DescribeFeatureType
NB : Quand OGC API Feature sera mis en oeuvre côté GPF, il sera à priori de reprendre ce principe pour renvoyer un schéma rédigé plus riche qu'un schéma généré par un outil tel GeoServer ou pg_featureserv.
Remarques
- Les propriétés "minOccurs", "maxOccurs" et "nillable" ne sont pas exploitées par ... mais l'intérêt semble modéré vu le remplissage. Par exemple, avec BDTOPO_V3:batiment, on voit que tout les champs sont "nillable".
Metadata
Metadata
Assignees
Labels
No labels