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

mrajerison · Avril 9, 2021, 6:27

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

NBerthelot · Avril 9, 2021, 7:53

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 »/

mrajerison · Avril 9, 2021, 12:24

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.)

NBerthelot · Avril 9, 2021, 1:55

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…

johan · Avril 10, 2021, 12:40

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.

mrajerison · Avril 10, 2021, 7:32

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

johan · Avril 13, 2021, 1:32

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 !

mrajerison · Avril 21, 2021, 8:45

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.

cquest · Avril 21, 2021, 9:21

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

voie1,regl1|regl2,geom_voie1

mrajerison · Avril 21, 2021, 12:20

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.

mrajerison · Avril 22, 2021, 1:01

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.

johan · Mai 2, 2021, 5:51

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.

mrajerison · Mai 3, 2021, 9:16

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 !

mrajerison · Septembre 9, 2021, 7:22

Bonjour,

Nous sommes heureux de vous annoncer la publication sur schema.data.gouv.fr d’un schéma pour dématérialiser les arrêtés de circulation pour le transport de marchandises.

Ce travail, réalisé par le Cerema, en partenariat avec La Région Sud et l’association OpenDataFrance, intervient dans le cadre de réflexions menées lors de la Fabrique de la Logistique, et d’une convention avec La Région Sud, au sujet de la dématérialisation des arrêtés de circulation et la publication de jeux de données relatifs à ces arrêtés sur le portail DataSud.

Il rejoint une initiative similaire conduite en Île-de-France, appelée BAC IDF visant à concentrer, numériser et mettre à disposition les arrêtés de circulation pour la logistique en ville.

Après pas mal de tâtonnements : création d’un environnement de saisie sous logiciel SIG, la publication d’un schéma sur schema.data.gouv.fr nous a semblés la meilleure option, notamment car celle-ci fait éclore automatiquement une myriade de solutions, à savoir un validateur de données et un éditeur de données de qualité en ligne.

Vous trouverez sur la page du schéma des tutoriels de création de données ainsi que des exemples de fichiers saisis selon ce schéma.

Le schéma vient accompagné d’un assistant (groom-groom) qui permet au quidam de récupérer la chaîne Opening Hours relative aux jours et heures de circulation autorisés (ou interdits), ou la géométrie de rues sur lesquelles s’applique une règlementation de la circulation.

Nous avions déjà réalisé un appel à contributions pour ce schéma à partir duquel nous avons fait évoluer le schéma; ce dernier est toujours actif.

Nous sommes toujours preneurs de vos retours, et les intègrerons dans une v0.7 du schéma.

Merci à tous ceux, notamment les personnes ayant participé à ce fil de discussion, de nous avoir aidés

cquest · Septembre 9, 2021, 7:46

Dans le schema, une erreur sur l’exemple avec coordonnée GPS… le description dit long,lat et l’exemple utilise lat,long

Il est vraiment dommage d’avoir mis ces coordonnées dans un champ texte descriptif, vraiment une drôle d’idée alors que je vois qu’il y a un champ WKT complet.

Dommage pour l’ID qui ne garantit pas d’unicité globale, mais locale, un ID composé du code INSEE de la collectivité + N° d’arrêté + partie unie aurait été bien plus intéressant pour l’agrégation.

J’ai créé 2 PR: https://github.com/CEREMA/schema-arrete-circulation-marchandises/pulls

mrajerison · Septembre 9, 2021, 8:02

Merci pour ce retour ! Nous allons corriger ça.

Pour les coordonnées GPS, tu mentionnes le champ EMPRISE_DEBUT et EMPRISE_FIN. Ces champs désignent les extrêmités de la voie sur laquelle s’applique la règlementation. Car un règlement peut s’appliquer seulement à une portion de voie, et non à la voie entière. EMPRISE_DEBUT et EMPRISE_FIN peuvent à la fois contenir du texte (intersection de rue xxx et rue yyy) ou des coordonnées GPS. Le plus souvent, ces informations sont textuelles dans les arrêtés, et il peut être assez compliqué pour un opérateur de récupérer les coordonnées GPS de ces extrêmités. Néanmoins, s’il y parvient, rien ne l’empêchera de les renseigner dans EMPRISE_DEBUT et EMPRISE_FIN (une regex permettrait de savoir si description textuelle ou coordonnées GPS).

Concernant le champ GEOM_WKT : dans le meilleur des cas, ce champ est rempli, mais il peut difficilement remplacer les champs EMPRISE_DESIGNATION, EMPRISE_DEBUT, EMPRISE_FIN. Sans doute, la majorité des producteurs de données saisiront des informations textuelles dans EMPRISE_DESIGNATION, EMPRISE_DEBUT, EMPRISE_FIN, d’après les informations contenues dans les arrêtés, et ne mettrons pas la géométrie directement dans GEOM_WKT, car cela demande une certaine technicité.

Le géoréférencement (remplissage de GEOM_WKT) peut intervenir par la suite, dans une seconde passe, en s’appuyant sur les informations renseignées dans MPRISE_DESIGNATION, EMPRISE_DEBUT, EMPRISE_FIN. En tout cas, c’est comme cela que nous imaginons les choses, mais cela reste discutable

Pour l’ID, nous avons proposé, dans la description, d’utiliser heidi d’Etalab pour garantir l’unicité globale, et faciliter le remplissage des identifiants.

Merci pour les PR

cquest · Septembre 9, 2021, 8:43

Je comprends bien, mais inclure dans un champ textuel des données dans un format non définit (il n’y a pas de regexp de validation de la façon d’insérer ces coordonnées), c’est être à peu près sûr d’avoir n’importe quoi au final et donc inutilisable. Ajouter deux champs lat/lon debut/fin serait quand même bien plus carré.

Oui, donc pour espérer avec quelques chose de géographique, il faudra croiser les doigts pour que ça se trouve quelque part et pas trop mal formatté dans un champs en texte libre… inutilisable dans la majorité des cas.

Là tu décris un process métier, si possible interne… c’est pas tellement le but d’un schema.

Oui, une sorte d’UUID qui n’en est pas un, mais comme rien ne l’impose ça n’a au final pas grand intérêt qu’il soit unique. Je ne saisit même pas l’intérêt de « heidi », il y a une API pour les récupérer automatiquement lors d’un traitement ou c’est juste un clicodrome ?

Un UUID (lié au hardware via l’adresse MAC pour ceux version 1 ou 2 sauf erreur) permet d’avoir une unicité globale.
Il y a de nombreuses librairies logicielles qui permettent de les générer et c’est même définit par une norme ISO et surtout un RFC 4122 (libre lui !).

mrajerison · Septembre 9, 2021, 10:16

Dans une précédente version du schéma, nous avions inclus deux champs GEOM_DEBUT et GEOM_FIN au format geopoint pour ces débuts et fin, en plus des champs textuels, mais les avions abandonnés afin de rendre le schéma plus léger. Était-ce une bonne idée de les enlever ? Peut-être pas.

Nous avons essayé de trouver un bon équilibre entre niveau technique requis pour produire la donnée et l’exigence de qualité nécessaire pour certains champs.

Dans tous les cas, les arrêtés existants ne font le plus souvent pas mention de coordonnées GPS, mais de mentions d’intersections, de carrefours qu’on ne peut omettre dans la donnée finale au format texte.

Il n’est pas que métier. Il est fonctionnel. Si le producteur ne peut saisir la géométrie de la rue dans GEOM_WKT sachant que les raisons peuvent être multiples (information imprécise, lacunaire, défaut de technicité), il pourra malgré tout saisir les informations de façon textuelle dans les trois champs EMPRISE_DESIGNATION, EMPRISE_DEBUT, EMPRISE_FIN.

Supprimer les champs EMPRISE_DESIGNATION, EMPRISE_DEBUT, EMPRISE_FIN me semble assez dangereux, et exiger en même temps GEOM_WKT freinerait la production de données. Règlementairement, je pense qu’il est indispensable de conserver les informations textuelles associées à la voie règlementée.

Et supprimer la colonne GEOM_WKT serait dommage, mais sans doute moins critique. Est-ce que cela vaudrait le coup de supprimer la colonne GEOM_WKT, d’après ce que tu dis ? Je suis assez mitigé.

Concernant le côté texte libre, il y a quand même une regexp censée contrôler si la ligne respecte le format WKT*.

Heidi est l’outil que l’équipe de schema.data.gouv.fr nous a conseillés. Son code source est ici. Nous nous sommes beaucoup questionnés sur cet ID. Je vais davantage me renseigner sur le format uuid, d’ailleurs inclus dans TableSchema. Mais un uuid pourra-t-il selon toi être facilement rempli par un opérateur après interprétation et numérisation d’un arrêté PDF ?

Je te remercie pour tes réponses. N’hésite pas à réagir. Je trouve cet échange très intéressant et constructif

*En aparté, je pense qu’il serait tout à fait utile que les outils d’édition intègrent une dimension saisie géo : de point, de ligne, de surface.

cquest · Septembre 9, 2021, 2:24

Il y a déjà tellement de champs optionnels, qu’on n’est plus à 4 champs près. 4 car il vaut mieux à mon avis avoir un champ lat_debut, lon_debut, lat_fin, lon_fin (qui ne sont que des nombres décimaux) qu’un « geopoint » assez éloigné d’une saisie dans un tableau/tableur/CSV et bien plus proche d’un SIG qui lui pourra en principe sortir le WKT de la voie.

Pour le WKT, c’est très bien et je n’ai pas suggéré (où à l’insu de mon plein gré) la suppression des champs textuels EMPRISE_xxx.

Pour le WKT, oui il y a une regexp, c’est pour les champs libres où il est suggéré de mettre les long/lat que c’est sans filet.

Les UUID sont générables par un algo (comme Heidi, mais eux sont standardisés), pas par un humain.
Au pire (Excel) il y a aussi des sites pour les générer en ligne: http://www.uuid.online/ ou même une formule magique https://gist.github.com/msubel/9c70951a20efe5c72195

mrajerison · Septembre 9, 2021, 3:12

Restaurer les 2 champs geopoint initiaux ou 4 champs décimaux : mon coeur balance…

Je fais le pari que les outils d’édition en ligne comme D-Lyne et publier.etalab.studio proposeront automatiquement, sur la base de cette formulation geopoint, des outils d’édition cartographique avec saisie de point pour ces champs (en fait, c’est déjà le cas pour D-Lyne).

Aussi, le format geopoint intègre de lui-même des contraintes de formatage propres aux coordonnées GPS tout en indiquant par son format la nature de l’information renseignée (géographique, de localisation).

La façon de formater ces champs pourra apparaître dans les exemples ou descriptions de champs. Aussi, je suppose qu’une personne qui sait remplir des colonnes long et lat d’un tableau sera en mesure de remplir une colonne unique long,lat

D’un autre côté, séparer long et lat permet sans doute un retraitement plus facile des champs sous un logiciel SIG. Nous allons peser le pour et le contre de chaque solution

Le côté universel d’uuid est intéressant. Malgré tout, l’outil uuid.online étant en anglais, je préfèrerais l’outil Heidi qui présente les mêmes fonctionnalités (excepté la génération d’uuid), mais en français, sachant que la langue française est un prérequis pour certains profils qui produiront des données.

Enfin, je pense qu’il n’y aura pas trop de risques de doublons avec Heidi, à l’échelle nationale, étant donnée l’allure des ID qu’Heidi produit, ex. 01FF5GKXXGWM2T55XRM3RX9ZHN

Merci beaucoup pour toutes ces remarques grâce auxquelles il y aura sans aucun doute une évolution du schéma, notamment la restauration des champs géométriques EMPRISE_DEBUT_POINT et EMPRISE_FIN_POINT ou la création de champs EMPRISE_DEBUT_LONG, EMPRISE_DEBUT_LAT, EMPRISE_FIN_LONG, EMPRISE_FIN_LAT

Ne pas hésiter s’il y a d’autres remarques ou d’autres idées !