FR:OSM History Renderer/Utilisation fullhistory

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

Merci à Ab_fab [[1]]

Installation

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

Installer les composants nécessaires de la rubrique "getting and building the tools"

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

Import des données

Pour télécharger 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 problème avec 16G de ram

performence/issue du programme

utilisation du paramètre nodestore

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

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

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 à osmium

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

filtrage des données

Si on ne désire pas découper en région, on peut utiliser osmconvert et osmfilter pour filtrer avec le critère voulu

Convertion du fichier history pour être utilisable par osmfilter (osmfilter ne gère 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 bâtiments par région en France : ~ 20 mn pour l'import et l'analyse sql du nombre de bâtiments

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

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 colonnes des tables

id	id de l'objet osm
version	version osm de l'objet
visible	attribut visible d'osm. false = effacé (le champ tags est vide)
minor	Pour les way : un way dont un node est modifié, n'est pas modifié en tant que way mais sa géométrie a changée. Le programme gère ces changements en attribuant un numéro de version minor.
valid_from	timestamp de début 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 nécessaire de refaire une projection 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ériodes voulues : modifier la valeur xx de generate_series(0,xx,1)

Nombre de bâtiments, 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 : nécessite de modifier fstab, postgresql.conf (data_directory)

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

nouveau poly de la France métropolitaine

le fichier par défaut (geofabrick) incluait les iles anglo-normandes

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

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

la géométrie par défaut était 90093. (le linéraire de la géometrie n'est pas en mètre : 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 champ "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