Il manque les champs :
description_sol
description_etat_sanitaire
date_releve
geometry (type point coordinates) [montpelllier.json]
circonference
photo_associee [hauts-de-seine.json]

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 ?

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 :

• corriger le nom du schéma en "arbres-urbains" dans le fichier schema.json à la ligne 3
• faire un commit de modification dans la branche master
• faire une nouvelle release avec un tag git

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

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

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

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.

il serait intéressante de fournir quelques exemples de transformation de fichier avec des outils de type OpenRefine?

https://openrefine.org/download.html

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

Comment mapper le schema sur le schema d'openstreetmap ?
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree
Merci

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.

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 ?

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 !

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

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.

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

On nous a signalé des incohérences dans les fichiers "exemple_valide" sur le code INSEE et le code postal.

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.