WikiProject France/Open Data Hauts-de-Seine Arbres

From OpenStreetMap Wiki
Jump to: navigation, search

Les données concernant les arbres du département des Hauts-de-Seine sont publiées sur le portail Open Data du Conseil Général des Hauts-De-Seine.

Cette page a pour objet le suivi de 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 à http://opendata.hauts-de-seine.net/jeu-de-donnees/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

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=WikiProject_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 à http://opendata.hauts-de-seine.net/jeu-de-donnees/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

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=WikiProject_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 à http://opendata.hauts-de-seine.net/jeu-de-donnees/arbres-remarquables-du-territoire-des-hauts-de-seine-hors-proprietes-privees

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

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=WikiProject_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 :

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::UserAgent
  • Ingestion du CSV à l'aide de Text::CSV_XS
  • Ré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-Seine
  • Filtrage du résultat par expressions Xpath de XML::LibXML
  • Jointure entre les jeux de données, identification des cas de modification
  • Transcodages
  • Gé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 CG92

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 :

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.