FR:OSM History Renderer/Utilisation fullhistory

From OpenStreetMap Wiki
Jump to: navigation, search

Memento pour l'utilisation statistique d'une base de données postgresql avec les données history d'openstreetmap

Merci a Ab_fab [[1]]

Installation

Il suffit de suivre les indications fournies par MaZderMind dans ce tutoriel : [2]

Installer les composants necessaires de la rubrique "getting and building the tools"

Creer la base postgresql comme indiqué dans la rubrique "creating the database"

Import des données

Pour telecharger les extracts history, voir ce lien : History_Planet

Je ne désire "travailler" que sur la france : il faut "splitter" ce fichier avec osm-history-splitter

L'import se fait en utilisant osm-history-importer :

osm-history-importer -l france-osh.pbf

l'option -l pour ne pas faire de transformation de géometrie

Probleme de mémoire

Les fichiers pbf de moins de 300M ne posent aucun probleme avec 16G de ram

performence/issue du programme

utilisation du parametre nodestore

osm-history-importer --nodestore sparse france-osh.pbf

sept 2014 : 180G d'espace disque utilisée par la base postgresql. 11G de ram utilisé pendant l'import + 2.5G de fichier swap. 24H d'import, 383 millions de node, 22.8 millions de line, 71 millions de polygone

le log de postgresql est rempli de message : consider increasing the configuration parameter "checkpoint_segments"

utiliser des fichiers plus petit

osm-history-splitter

osm-history-splitter [[3]] permet de générer en une fois plusieurs fichiers par région plus petite

le nom du fichier history doit obligatoirement avoir le mot "osh" dans son extension (myfile.osh.pbf par exemple) : c'est une limitation due a osmium

L'extraction de la france métropolitaine a partir du fichier history mondial dure a peu près 4h

filtrage des données

Si on ne désire pas decouper en region, on peut utiliser osmconvert et osmfilter pour filtrer avec le critere voulu

Convertion du fichier history pour etre utilisable par osmfilter (osmfilter ne gere pas les pbf)

osmconvert france.osh.pbf --out-osh -out-o5m>france.osh.o5m

Filtrer les données voulues

osmfilter france.osh.o5m --out-osh --keep="highway=" --drop-relations > france-way.osm

Temps de traitement

Fichier filtré des batiments par région en france : ~ 20mn pour l'import et l'analyse sql du nombre de batiment

Fichier france.osh.pbf : 24h, ~ 30mn pour l'analyse sql du nombre de batiment ou du kilométrage de voierie

Structure des tables de la base postgres

Par défaut, la projection utilisée est 90093. l'import génére 3 tables : hist_line, hist_point, hist_polygon. Ci après les principales colones des tables

id id de l'objet osm
version version osm de l'objet
visible attribut visible d'osm. false = effacé (le champs tags est vide)
minor Pour les way : un way dont un node est modifié, n'est pas modifié en tant que ways mais sa géométrie a changée. le programme gere ces changements en attribuant un numéro de version minor.
valid_from timestamp de debut de la version/minor de l'objet
valid_to timestamp de fin de la version/minor de l'objet
tags champs contenant tous les tags de l'objet

Analyses

comptabilisation du nombre voie et de km, par type de voie et par an

La base utilisée est hist_line. La projection étant en 90093, l'unité de longueur n'est pas le mètre, il est necessaire de reprojecter en lambert93.

select
 tt as annee,
 tags->'highway' as typedevoie,
 count(geom),
 round(sum(ST_Length(ST_Transform(geom,2154))) / 1000) as kilometers
from 
 hist_line,
(SELECT date '2007-01-01' + interval '1' year * s.a AS date
 FROM generate_series(0,7,1) AS s(a)) AS Checking (tt)
where
visible AND
 tags ? 'highway' AND
 tags->'highway'
        IN (
          ('motorway'),
          ('motorway_link'),
          ('trunk'),
          ('trunk_link'),
          ('primary'),
          ('primary_link'),
          ('secondary'),
          ('secondary_link'),
          ('tertiary'),
          ('tertiary_link'),
          ('unclassified'),
          ('residential'),
          ('living_street'),
          ('road'),
          ('service'),
          ('track'),
          ('path')
       ) 
 and
 tt::timestamptz BETWEEN valid_from AND COALESCE(valid_to, '9999-12-31')
group by tt, tags->'highway'
order by tt, tags->'highway';
  • date '2007-01-01' est le début de la période
  • On peut modifier la période : "interval '1' year" par '1' month
  • Le nombre de période voulue : modifier la valeur xx de generate_series(0,xx,1)

Nombre de batiment , par mois, sur 7 ans

Ici la base utilisée est hist_polygon

select
 tt as annee,
 count(geom)
from 
hist_polygon,
(SELECT date '2007-01-01' + interval '1' month * s.a AS date
 FROM generate_series(0,7*12,1) AS s(a)) AS Checking (tt)
where
 visible AND
 tags ? 'building' AND
 tt::timestamptz BETWEEN valid_from AND COALESCE(valid_to, '9999-12-31')
group by tt
order by tt

New import avec

disque plus rapide

1T velociraptor : necessite de modifier fstab, postgresql.conf (data_directory)

le temps de l'import passe de 24h a 12h (avec 9 mois d'historique en plus)

nouveau poly de la France métropolitaine

le fichier par defaut (geofabrick) incluait les iles anglo-normandes

"split" du fichier history mondial : http://planet.openstreetmap.org/planet/experimental/history-2014-09-29.osm.pbf : 4h

ajout d'un champ a la base avec la geometry en lambert93

la geometrie par defaut etait 90093. (le linéraire de la géometrie n'est pas en metre : merci cquest)

ALTER TABLE hist_polygon ADD COLUMN geom93 geometry(Polygon,2154);
update hist_polygon set geom93=ST_Transform(geom,2154)
ALTER TABLE hist_line ADD COLUMN geom93 geometry(LineString,2154);
update hist_line set geom93=ST_Transform(geom,2154)

To Do

Trouver comment analyser les ways effacés (identifiable avec le champs "visible") car ils n'ont pas de tag

select 
   hist_polygon.id, hist_polygon.tags
from 
   hist_polygon
   inner join (select id from hist_polygon where not visible limit 500) as eff on eff.id=hist_polygon.id
where 
   hist_polygon.visible