France/Open Data Hauts-de-Seine Arbres
Les données concernant les arbres du Département des Hauts-de-Seine sont publiées sur le portail Open Data du Conseil Départemental des Hauts-De-Seine.
Cette page a pour objet le suivi de leur exploitation pour OpenStreetMap et la description du processus de synchronisation.
Statut : en cours de développement par Jean-Marc Liotier, après qu'il l'ai laissé en plan pendant deux ans
Bien entendu, le code sera publié et discuté avant tout import !
Sources
Généralités
Selon le portail Open Data Hauts-de-Seine, "chaque arbre est dans un seul jeu de données". Nous considérons donc ces trois jeux de données comme une source unique avec un espace de nommage commun.
Il semble que les coordonnées X et Y représentent longitude et latitude WGS84, même si ce n'est pas explicitement indiqué.
Arbres du cadastre vert
Statut
En attente de développement.
Contenu de la source
Données publiées à https://opendata.hauts-de-seine.fr/explore/dataset/cadastre-vert-les-arbres
Intitulé du champ | Description du champ | Type | Valeur |
IDELEMENT_ | Identifiant de l'arbre | Numérique | |
CODE_INSEE | Code Insee de la commune | Numérique | CCCCC |
COMMUNE | Commune de l'arbre | Texte | |
CIRCONF | Circonférence de l'arbre | Numérique | |
TYPE | Type de l'arbre | Texte | Isolé, aligné |
DIAMETRE | Diamètre de l'arbre (mètres) | Numérique | |
X | Coordonnée X (longitude) de l'arbre | Numérique | |
Y | Coordonnée Y (latitude) de l'arbre | Numérique | |
Analyse des données exploitables
Retenues
Le commentaire du champ CIRCONF de la source annonce "circonférence de l'arbre" - quelle partie de l'arbre est mesurée ? Les valeurs présentes dans le champ CIRCONF sont typiquement de l'ordre du mètre (en supposant que l'unité de mesure est le mètre - ce qui parait très probable vu que les valeurs présentes seraient incongrues pour une autre unité). On en déduit que le champ CIRCONF décrit la circonférence du tronc et qu'il peut être copié tel quel comme valeur de circumference=* si sa valeur est supérieure à zéro (les valeurs égales à zéro seront ignorées). Les valeurs de CIRCONF sont en notation scientifique - elles seront converties en notation décimale avec deux chiffres après la virgule.
TYPE peut être transcodé en denotation=avenue lorsque TYPE="aligné" ou vide sinon.
Non retenues
CODE_INSEE et COMMUNE sont redondants avec le positionnement géographique de l'arbre dans OpenStreetMap où il peut être intersecté avec les circonscriptions administratives. Ces attributs ne seront donc pas retenus.
DIAMETRE est redondant avec CIRCONF et par conséquent non retenu, d'autant plus que la mesure de la circonférence est beaucoup plus courante dans OpenStreetMap que la mesure du diamètre, cette dernière étant aussi plus compliquée à réaliser.
Correspondances retenues
- Etiquette natural=tree
- Position WGS84 (lat et long de <node>) définies par X et Y (à convertir de notation scientifique en notation décimale)
- ref:FR:CG92:arbres : IDELEMENT_
- source:date=* : date relevée à https://opendata.hauts-de-seine.fr/explore/dataset/cadastre-vert-les-arbres (actuellement 25/09/2012) convertie au format ISO 8601 (par exemple 2012-09-25)
- source=* : "CG92"
- source:URL=*: "http://wiki.openstreetmap.org/w/index.php?title=France/Open_Data_Hauts-de-Seine_Arbres#Arbres_du_cadastre_vert"
- circumference=* : CIRCONF
- denotation=avenue lorsque TYPE="aligné"
Exemple d'objet OpenStreetMap produit
<node id="-1" lat="48.8948723" lon="2.2556340" version="1" timestamp="2011-12-01T02:00:04Z"> <tag k="natural" v="tree"/> <tag k="ref:FR:CG92:arbres" v="381599"/> <tag k="source:date" v="2012-09-25"/> <tag k="source" v="CG92"/> <tag k="source:URL" v="http://wiki.openstreetmap.org/w/index.php?title=France/Open_Data_Hauts-de-Seine_Arbres#Arbres_du_cadastre_vert"/> <tag k="circumference" v="1.07219"/> <tag k="source:circumference" v="CG92"/> <tag k="denotation" v="avenue"/> <tag k="source:denotation" v="CG92"/> </node>
Arbres d'alignement sur la voirie départementale
Statut
En attente de développement.
Contenu de la source
Données publiées à https://opendata.hauts-de-seine.fr/explore/dataset/arbres-dalignement-sur-la-voirie-departementale
Intitulé du champ | Description du champ | Type | Valeur |
ID_ARBRE | Identifiant unique de l'arbre | numérique | |
COMMUNE | Nom de la commune | texte | |
CODE_INSEE | Code Insee de la commune | numérique | CCCCC |
NUM_RD | Numéro de la Route départementale | numérique | |
NOM_RUE | Nom de la rue | texte | |
NUM_EMP | Numéro de l'emplacement de l'arbre | numérique | |
ESSENCE_SC | Essence scientifique | texte | |
ESSENCE_CO | Essence nom courant | texte | |
CIRCONFERE | Circonference de l'arbre (cm) | numérique | |
HAUTEUR | Hauteur de l'arbre (mètres) | numérique | |
CLASSE_AGE | Classe d'âge | texte | jeune/adulte |
STATUT_EMP | Statut emplacement : Etat phytosanitaire | texte | |
DATE_MAJ | Date de mise à jour = date de l'extraction de la base | numérique | |
X | Coordonnée X (longitude) de l'arbre | Numérique | |
Y | Coordonnée Y (latitude) de l'arbre | Numérique | |
Analyse des données exploitables
Retenues
..
Non retenues
CODE_INSEE, COMMUNE, NUM_RD et NOM_RUE sont redondants avec le positionnement géographique de l'arbre dans OpenStreetMap où il peut être intersecté avec les circonscriptions administratives. Ces attributs ne seront donc pas retenus.
NUM_EMP est un type actuellement non connu dans OpenStreetMap - les suggestions de traitement sont bienvenues.
Correspondances retenues
- Etiquette natural=tree
- Position WGS84 (lat et long de <node>) définies par X et Y (à convertir de notation scientifique en notation décimale)
- ref:FR:CG92:arbres : ID_ARBRE
- source:date=* : DATE_MAJ convertie au format ISO 8601 (par exemple 2012-10-08)
- source=* : "CG92"
- source:URL=*: "http://wiki.openstreetmap.org/w/index.php?title=France/Open_Data_Hauts-de-Seine_Arbres#Arbres_d.27alignement_sur_la_voirie_d.C3.A9partementale"
- genus=* : premier mot de ESSENCE_SC
- species=* : ESSENCE_SC
- species:fr=* : ESSENCE_CO
- circumference=* : CIRCONFERE
- height=* : HAUTEUR
Exemple d'objet OpenStreetMap produit
<node id="-1" lat="48.8948723" lon="2.2556340" version="1" timestamp="2011-12-01T02:00:04Z"> <tag k="natural" v="tree"/> <tag k="ref:FR:CG92:arbres" v="9202600087"/> <tag k="source:date" v="2012-09-25"/> <tag k="source" v="CG92"/> <tag k="source:URL" v="http://wiki.openstreetmap.org/w/index.php?title=France/Open_Data_Hauts-de-Seine_Arbres#Arbres_d.27alignement_sur_la_voirie_d.C3.A9partementale"/> <tag k="circumference" v="0.32"/> <tag k="source:circumference" v="CG92"/> <tag k="genus" v="Cercis"/> <tag k="species" v="Cercis - siliquastrum - L. -"/> <tag k="source:species" v="CG92"/> <tag k="species:fr" v="Arbre de Judée"/> <tag k="source:species:fr" v="CG92"/> <tag k="height" v="6"/> <tag k="source:height" v="CG92"/> </node>
Arbres remarquables
Statut
En cours de développement.
Contenu de la source
Données publiées à https://opendata.hauts-de-seine.fr/explore/dataset/fr-229200506-arbres-remarquables
Intitulé du champ | Description du champ | Type | Valeur |
NOM_EV | Nom de l'espace vert de l'arbre remarquable | Texte | |
DIAMETRE | Diamètre (envergure) de l'arbre remarquable (mètres) | Numérique | |
CODE_INSEE | Code Insee de la commune | Numérique | CCCCC |
QUARTIER | Quartier de l'arbre remarquable | Texte | |
NOM_SCIENT | Nom scientifique de l'arbre remarquable | Texte | |
MATRICULE | Numéro de l'arbre | Numérique | |
NOM_VERNAC | Nom vernaculaire de l'arbre remarquable | Texte | |
RAYON | Rayon de l'arbre remarquable (mètres) | Numérique | |
X | Coordonnée X (longitude) de l'arbre | Numérique | |
Y | Coordonnée Y (latitude) de l'arbre | Numérique | |
Analyse des données exploitables
Retenues
Diamètre et rayon sont très rarement enregistrés dans OpenStreetMap - c'est généralement la mesure de la circonférence qui est retenue. Par souci d'uniformisation, nous proposons donc d'enregistrer la circonférence à partir de RAYON ou DIAMETRE suivant la disponibilité de ces valeurs.
Non retenues
CODE_INSEE et QUARTIER sont redondants avec le positionnement géographique de l'arbre dans OpenStreetMap où il peut être intersecté avec les circonscriptions administratives. Ces attributs ne seront donc pas retenus.
Correspondances retenues
- Etiquette natural=tree
- Position WGS84 (lat et long de <node>) définies par X et Y (à convertir de notation scientifique en notation décimale)
- ref:FR:CG92:arbres : MATRICULE
- source:date=* : date relevée à https://opendata.hauts-de-seine.fr/explore/dataset/fr-229200506-arbres-remarquables (actuellement 01/09/2012) convertie au format ISO 8601 (par exemple 2012-09-01)
- source=* : "CG92"
- source:URL=*: "http://wiki.openstreetmap.org/w/index.php?title=France/Open_Data_Hauts-de-Seine_Arbres#Arbres_remarquables"
- genus=* : premier mot de NOM_SCIENT
- species=* : NOM_SCIENT
- species:fr=* : NOM_VERNAC
- circumference=* : si DIAMETRE est présent est non-nul, pi*DIAMETRE, sinon si RAYON est présent et non nul, 2*pi*RAYON, sinon cette étiquette n'est pas enregistrée. Les valeurs enregistrées seront en notation décimale avec deux chiffres après la virgule.
Exemple d'objet OpenStreetMap produit
<node id="-1" lat="48.8948723" lon="2.2556340" version="1" timestamp="2011-12-01T02:00:04Z"> <tag k="natural" v="tree"/> <tag k="ref:FR:CG92:arbres" v="9202600087"/> <tag k="source:date" v="2012-09-25"/> <tag k="source" v="CG92"/> <tag k="source:URL" v="http://wiki.openstreetmap.org/w/index.php?title=France/Open_Data_Hauts-de-Seine_Arbres#Arbres_remarquables"/> <tag k="circumference" v="1.07219"/> <tag k="source:circumference" v="CG92"/> <tag k="genus" v="Acer"/> <tag k="source:genus" v="CG92"/> <tag k="species" v="Acer platanoides L."/> <tag k="source:species" v="CG92"/> <tag k="species:fr" v="Erable plane"/> <tag k="source:species:fr" v="CG92"/> </node>
Analyse des données existantes
Le 12 Février 2012, préalablement à l'intégration des jeux de données ici décrits, il y avait d'après une requête Overpass un nombre total de 428 natural=tree dans les Hauts-de-Seine. Il est probable qu'une partie de ces arbres existe déjà dans Openstreetmap - une conflation manuelle sera donc nécessaire lors du premier import.
Processus de synchronisation - génération du changeset
Création et modification
Pour chaque source de données, pour chaque enregistrement...
Si l'identifiant unique de l'arbre n'existe pas dans l'attribut ref:FR:CG92:arbres d'un objet d'OpenStreetMap, un objet est créé.
Si l'identifiant unique de l'arbre existe dans l'attribut ref:FR:CG92:arbres de plus d'un objet d'OpenStreetMap, alors un message d'avertissement est produit et l'enregistrement est ignoré.
Si l'identifiant unique de l'arbre existe dans l'attribut ref:FR:CG92:arbres d'un objet d'OpenStreetMap, alors... Pour chaque attribut géré par ce processus de synchronisation, si l'utilisateur utilisé par ce processus de synchronisation est le dernier modificateur de l'attribut, alors cet attribut est écrasés.
Alternativement à la gestion de l'écrasement des attributs par la connaissance de l'historique, une mécanisme plus simple serait d'utiliser un attribut source:attribut pour chaque attribut. Overpass suffirait alors à récupérer l'ensemble des données en une seule passe alors que la récupération de l'historique de chaque noeud via l'API v0.6 serait beaucoup plus lente et nécessiterait beaucoup plus de traitements. Le seul inconvénient de cette approche est la quantité de métadonnées insérées dans Openstreetmap.
La liste des attributs gérés par ce processus de synchronisation est la suivante :
- ref:FR:CG92:arbres
- position : position WGS84 définie par le couple X et Y
- source=*
- source:date=*
- source:URL=*
- genus=*
- species=*
- species:fr=*
- circumference=*
- height=*
- denotation=*
Le traitement individuel des attributs peut être source d'incohérences mais il permet un meilleur respect des contributions fragmentaires - est-ce le bon compromis ?
Suppression des arbres dans OpenStreetMap
Pour chaque objet OpenStreetMap portant un attribut ref:FR:CG92:arbres absent du modèle intermédiaire, ajout d'un attribut 'FIXME=Existence à vérifier - cet arbre est absent de la source à partir de laquelle il a été créé'.
Si un contributeur considère que l'arbre existe et qu'ignoré par le CG92 il ne doit plus être soumis aux affres de la synchronisation, alors il peut supprimer l'attribut ref:FR:CG92:arbres - mais le contributeur irrité par l'ajout récurrent du FIXME saura-t-il que c'est la solution à son problème ?
Implémentation
Généralités
L'exécution du script de synchronisation générera un changeset au format OSM XML contenant l'ensemble des modifications nécessaires pour la synchronisation. L'utilisateur responsable de l'intégration des données validera ce changeset dans JOSM avant de le verser dans Openstreetmap.
Chaque jeu de données aura son propre script - construit selon le même modèle mais traitant son cas spécifiquement.
Statut
Le script implémentant l'ensemble du processus est en cours de développement en Perl.
Détail des réalisations en cours:
Identification et récupération des données sources en CSV à l'aide de LWP::UserAgentIngestion du CSV à l'aide de Text::CSV_XSRécupération des données Openstreetmap via Overpass à l'aide du polygone issu de la relation représentant la frontière administrative des Hauts-de-SeineFiltrage du résultat par expressions Xpath de XML::LibXMLJointure entre les jeux de données, identification des cas de modificationTranscodagesGénération du XML des nouveaux noeuds- Identification des cas de modification et génération du XML des noeuds modifiés (en cours)
- Génération du XML traitant les cas d'arbres disparus dans la source
Récupération des données du CD92
Les données sont offertes au format CSV.
Voici les commandes permettant de récupérer le fichier nommé au format Arbres_20120413.csv quel que soit le suffixe de date :
wget -O Arbres.csv http://opendata.hauts-de-seine.net/sites/default/files/espace_public/dataset/537/resources/`wget -qO- http://opendata.hauts-de-seine.net/jeu-de-donnees/cadastre-vert-les-arbres | egrep -o "Arbres_2[0-9]{7,}\.csv" | uniq`
wget -O Arbres_alignement.csv http://opendata.hauts-de-seine.net/sites/default/files/espace_public/dataset/464/resources/`wget -qO- http://opendata.hauts-de-seine.net/jeu-de-donnees/arbres-dalignement-sur-la-voirie-departementale | egrep -o "Arbre_Alignement_RD_2[0-9]{7,}\.csv" | uniq`
wget -O Arbres_remarquables.csv http://opendata.hauts-de-seine.net/sites/default/files/espace_public/dataset/391/resources/`wget -qO- http://opendata.hauts-de-seine.net/jeu-de-donnees/arbres-remarquables-du-territoire-des-hauts-de-seine-hors-proprietes-privees | egrep -o "Arbre_remarquable_2[0-9]{7,}\.csv" | uniq`
C'est ce suffixe de date qui sera utilisé pour renseigner source:date=*
Ingestion du CSV, sélection des champs et transcodage
Transcodages :
- Conversion en notation décimale des notations scientifiques utilisées dans ce jeu de données
- Conversion des dates au format ISO 8601
Récupération des données OpenStreetMap
Exemple : sélection des natural=tree des Hauts-de-Seine :
area[name="Hauts-de-Seine"]; (node[natural=tree] (area);<;); out;
Cette requête prend en argument la relation frontière des Hauts-de-Seine.
Exemple : sélection de platanes des Hauts-de-Seine (pas tous parce que l'étiquetage avec natural=tree et genus=* ignore ceux qui n'utilisent que species=* - d'ailleurs là où elles mentionnent l'espèce, les données du CG92 ne permettent que de renseigner species=*)
area[name="Hauts-de-Seine"]; (node [natural=tree] [genus=Platanus] (area);<;); out;
Reste à y rajouter en critère la présence d'un attribut ref:FR:CG92:arbres - une clause node["ref:FR:CG92:arbres"]; à placer quelque part dans la requête ci-dessus.
La requête correspondant à nos besoins sera donc ;
area[name="Hauts-de-Seine"]; (node [natural=tree] ["ref:FR:CG92:arbres"] (area);<;); out;
et la requête Overpass équivalente est:
<osm-script> <query into="_" type="area"> <has-kv k="name" modv="" v="Hauts-de-Seine"/> </query> <union into="_"> <query into="_" type="node"> <has-kv k="natural" modv="" v="tree"/> <has-kv k="ref:FR:CG92:arbres" modv="" v=""/> <area-query from="_" into="_" ref=""/> </query> <recurse from="_" into="_" type="up"/> </union> <print e="" from="_" geometry="skeleton" limit="" mode="body" n="" order="id" s="" w=""/> </osm-script>
Et pour la soumettre:
wget --post-file="ref_FR_CG92_arbres.overpass" -O "ref_FR_CG92_arbres_overpass.osm" "http://overpass-api.de/api/interpreter"
Sinon, le même résultat peut être obtenu à partir d'un extrait de Planet - mais c'est un marteau pour écraser une mouche:
wget http://download.geofabrik.de/europe/france/ile-de-france-latest.osm.pbf osmosis \ --read-pbf file=ile-de-france-latest.osm.pbf \ --tf accept-nodes ref:FR:CG92:arbres=* \ --tf reject-relations \ --tf reject-ways \ --write-xml ref_FR_CG92_arbres.osm
Les requêtes à l'intérieur des données résultantes auront lieu localement à l'aide de XML::LibXML, afin d'accélérer l'exécution et d'économiser les appels à Overpass. L'implémentation utilisera des expressions Xpath et l'itération sur les <node> renvoyés par Overpass.
Détection des données OpenStreetMap divergentes
C'est le marquage par l'attribut source:attribut qui déterminera les attributs dont le présent outil est le dernier modificateur. Si un utilisateur souhaite reprendre le contrôle, il lui suffira de modifier les sources:attribut ayant pour valeur "CG92" avec lesquelles ce script identifie les champs sur lesquels il est maître. Pour chaque attribut géré, c'est donc l'attribut source:attribut qui déterminera si sa valeur est écrasée par la synchronisation de la source vers OpenStreetMap (recherche d'un noeud dont un attribut spécifié a une valeur donnée).
Génération et application du changeset
Le format de <node> est identique entre la sortie d'Overpass et le format OsmChange. Le changeset contenant les <node> créés ou modifiés sera généré par XML::LibXML au format OsmChange et enregistré dans un fichier.
En production, l'application du changeset aura lieu via Osmosis et sous l'identité d'une utilisateur dédié à cet import.
Tests
L'implémentation sera testée sur un serveur hors production, dont l'identité reste à définir.
Une fois la VABF passée, la VSR aura lieu avec le jeu de données "Arbres remarquables" (le plus petit des trois) - d'abord avec un échantillon, puis avec le jeu complet. Il sera suivi par "Arbres d'alignement sur la voirie départementale" puis par "Arbres du cadastre vert" dont la taille importante pourrait nécessiter le découpage du changeset généré.
Surveillance de la source
La date de publication peut être extraite du nom de fichier trouvé dans la page du jeu de données. Un script exécuté quotidiennement automatiquement détectera le changement de cette date et en alertera une liste de diffusion qui générera aussi un élément de flux RSS.