naturalsolutions / schema-arbre Goto Github PK
View Code? Open in Web Editor NEWModélise les attributs des arbres urbains
Home Page: https://www.natural-solutions.eu/
License: Other
Modélise les attributs des arbres urbains
Home Page: https://www.natural-solutions.eu/
License: Other
Bonjour,
Il manque la description pour le champs "espece_arbre".
{ "name":"espece_arbre", "description":"", "example":"", "type":"string", "constraints":{ "required":false }
Le champs précédent est :
{ "name":"genre_arbre", "description":"La subdivision de la famille auquel appartient l'arbre en latin (sixième niveau de la classification classique).", "example":"Platanus", "type":"string", "constraints":{ "required":false }
Je me demandais alors si quelqu'un.e aurait la description pour le champs "espece_arbre" ?
Merci par avance !
Souvent, dans certains jeux de données, la partie "_arbre" vient compléter le nom du champ. Cela est dans la plupart des cas inutile
La métropole de Lyons utilise le concept de gestion différentiée pour l'arbre en ville
Je pense que ce champs numérique (1-5) pourrait être ajouter au schema.
On nous a signalé des incohérences dans les fichiers "exemple_valide" sur le code INSEE et le code postal.
Hello,
Je me permet d'ajouter deux issues (séparées même si c'est sûr le même problème).
Le DHP (diamètre à hauteur de poitrine) se mesure sur les arbres urbains soit à 1,3m (comme en forêt ou partout dans le monde) soit à 1,0m a cause de certains barèmes de l’arbre cf. indice 4 dans le lien qui suit (https://www.loiret.fr/sites/loiret/files/media/documents/2020/05/bareme-evaluation-valeur-arbre-05042020.pdf). Pour résoudre ce petit problème je propose DHP_1m et DHP_1_3m (pas folichon le second). Qu'en pensez vous ?
En général le DHP est en cm mais j'ai pu en voir en mm. Si on garde la hauteur ou il est pris pour le nom on est coincé pour l'indiquer dans le champ. On pourrait aussi le fixer dans le standard. J'ai pas d'opinion sur la question.
Bonjour,
Bravo et merci pour le temps pris pour réaliser ce schéma.
Afin de pouvoir s'interfacer correctement avec schema.data.gouv.fr, il faudrait que vous ajoutiez une release de ce repo via la création d'un tag Github. Vous pouvez prendre exemple sur https://github.com/etalab/schema-lieux-covoiturage et https://github.com/etalab/schema-lieux-covoiturage/tags
Ce tag permettra de figer une version du schéma dans le temps et permettra d'éviter les erreurs lors du développement d'éventuelles nouvelles fonctionnalités sur le master (schema.data.gouv.fr ne s'interface qu'avec des releases de schéma).
A votre disposition si besoin d'aide,
Geoffrey
En lien avec data.gouv.fr et schema.data.gouv.fr, nous travaillons actuellement sur une montée de version de l'outil de validation Validata.fr, afin de prendre en compte la nouvelle version du framework de validation (frictionless-py
) utilisée par Validata.
La nouvelle version frictionless-py
impose une nouvelle spécification pour les schémas : la propriété 'name' ne doit pas comporter de majuscule ni d'espace. De manière générale elle doit respecter la regex suivante : ([-a-z0-9._/])+$
De ce fait, le schéma Arbres Urbains référencé sur schema.data.gouv.fr, nommé "Arbres urbains" devient donc désormais invalide.
Pour corriger cela, vous pouvez :
Nous vous invitons à corriger le schéma avant le 29/02/2024, au delà de cette date, il sera déréférencé de schema.data.gouv.fr
Il manque les champs :
description_sol
description_etat_sanitaire
date_releve
geometry (type point coordinates) [montpelllier.json]
circonference
photo_associee [hauts-de-seine.json]
Il faudrait réfléchir à l'utilité d'avoir plusieurs champs similaires tels que :
description_pied et type_enracinement
description_sol et contraintes_sol
zip_code, code_postal, code, code_commune et township_code
zone
Comment mapper le schema sur le schema d'openstreetmap ?
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree
Merci
Pour bon nombre d'attribut, il conviendrait de fournir des listes de valeurs (ouvertes/fermées) pour faciliter son implémentation.
Par exemple :
type_enracinement
port_arbre
La documentation du champs id
indique :
un identifiant unique de l'objet arbre
mais ça n'est pas très informatif. Unique à quelle échelle ? À l'échelle du fichier lui même, de la commune, communauté de commune, du pays ?
Par ailleurs, quelle est le scope temporel de cette identifiant ? Est-ce que le même arbre doit forcément avoir le même identifiant dans deux versions successives du fichier ?
Le problème de l'unité de la hauteur de l'arbre est plus fréquent mais on a des cas en m d'autres en dm et enfin parfois on a des catégories. J'ajoute que l'on a pas souvent le même niveau de précision.
Dans tous ces cas c'est simple de le détecter avec un peu de bon sens mai cela finit par être coûteux en temps. Faut-il le fixer dans un standard ?
Après plusieurs échanges avec différentes communes, le nouveau barème de l'arbre commence à être pas mal utilisé. C'est une démarche qui doit être soutenue et mise en valeur. Il serait donc intéressant de rajouter certains champs qui permettent de calculer le VIE.
il serait intéressante de fournir quelques exemples de transformation de fichier avec des outils de type OpenRefine?
Bravo pour ce nouveau schéma qui va je pense rencontrer un certain succès ! 👏 Je vous encourage à contacter OpenDataFrance car cela mériterait d'être popularisé auprès des collectivités dans le cadre du SCDL. 👍
J'ai cependant constaté un petit problème pas compliqué à réparer :
Depuis Validata, quand on veut tester la validation des fichiers exemple valides, on rencontre ce message : "Une erreur est survenue lors de la validation". En effet, pour les 2 versions du schéma publiées (v0.1.0
, v0.2.0
), les URL des fichiers du champ resources
sont cassées et par conséquent Validata ne peut pas retrouver les fichiers.
Les URL pointent vers un dépôt schema-objets-arbre
qui a probablement été renommé en schema-arbre
par la suite. Par ailleurs, dans la version 0.2.0 du schéma, le tag pointé dans les URL est toujours v0.1.0
et les informations dans les champs version
et lastModified
n'ont pas non plus été mises à jour.
Bonjour,
Par expérience, je vous propose de modifier le type informatique des champs optionnels dont les réponses sont vrai/faux ou oui/non en passant en texte (1) plutôt qu'un boolean car il faut pouvoir gérer des valeurs NULL.
Si cela ce gère bien dans un SGBD, les exports sont parfois douteux selon les outils et surtout les formats de fichiers qui transforment les NULL en valeur "faux". On a un risque de dénaturation de l'information à cette occasion.
Attributs concernés :
arbre_protege
arbre_remarquable
eclairage
Je pense qu'on peut inclure la liste des fichiers d'arbres ouvert ici
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.