DE:HowTo minutely hstore

Dieses HowTo beschreibt Schritt für Schritt, wie man einen eigenen Openstreetmap-Server inklusive einer osm2pgsql Datenbank mit hstore Spalte in einer Linux-Umgebung einrichten und mittels der minütlichen Diffs auf dem neusten Stand halten kann.

Eine vorbereitete virtuelle Maschine, welche dieses HowTo und HowTo Mapnik & Tirex beinhaltet, kann via BitTorrent heruntergeladen werden: HowTo minutely hstore/VM.

Eine Datenbank im osm2pgsql-Schema kann für fast alle darstellenden Zwecke (Mapnik, Tileserver, OpenLayers POIs) verwendet werden. Da sie keine Informationen über die Schnittpunkte der einzelnen Straßen und Wege bereitstellt, kann sie jedoch nicht für Routing oder API-Updates verwendet werden. Normalerweise enthält eine Datenbank im osm2pgsql-Schema nur ausgewählte Tags (z.B. amenity, highway und name) und seltenere Tags (z.B. drink:club-mate, traffic_signals:sound) werden einfach verworfen. In der hstore Spalte werden hingegen alle verwendeten Tags, wie selten sie auch sein mögen, festgehalten und sind auch durchsuchbar. Die minütlichen Diffs werden von openstreetmap.org in Schnitt einmal je Minute herausgegeben und enthalten alle Änderungen, die in der letzten Minute stattgefunden haben. Sie werden verwendet um die eigene Datenbank aktuell zu halten.

System

In diesem HowTo verwenden wir eine Debian 5.03 Basis-Installation. Um eine Planet-Datenbank minütlich aktuell zu halten und auf derselben Maschine auch noch Tiles zu rendern, braucht es schon ein recht starkes System. Eine Beispielkonfiguration, die auf dem deutschen OSM Dev-Server verwendet wird, wäre z.B. 4 CPUs à 2.3 GHz und 16 GB RAM. An Festplattenplatz benötigt man mindestens 200 GB für die Datenbank und, je nachdem auf welche Bereiche der Welt Zugriffe erwartet werden, 100 GB bis 300 GB für die vorgerechneten Tiles. Es empfiehlt sich LVM (Logical Volume Manager) zu verwenden und je eine extra Partition für die Datenbank und die Tiles zu verwenden.

Software

Als Datenbank-Software wird PostgreSQL 8.3 verwendet (mit aktuellen osm2pgsql-Versionen sind aber auch 8.4 oder 9.0 einsetzbar). Für die Geographie-Informationen wird die PostGIS-Erweiterung benutzt. Unter einigen Distributionen ist auch „postgresql-8.3-hstore-new“ als Paket verfügbar. Da dies für das hier verwendete „Debian Lenny“ nicht gilt, übersetzen wir hstore-new später selbst. Ansonsten empfiehlt es sich jedoch, das fertige Paket zu benutzen. Es ist sehr wichtig "hstore-new" zu benutzen. Es gibt noch ein altes hstore Plugin, dies ist jedoch sehr instabil und sollte nicht verwendet werden!

Um Quellcodes herunter zu laden benötigen wir subversion und cvs und zum Übersetzen die build-essentials, autoconf und einige dev-Pakete. Für Osmosis benötigen wir außerdem Java. Osmosis läuft am besten mit Sun’s JRE. Damit diese installiert werden kann, muss die Datei „/etc/apt/sources.list“ wie folgt geändert werden:

deb http://ftp.de.debian.org/debian/ lenny main non-free contrib
deb http://backports.debian.org/debian-backports lenny-backports main

Installiert werden kann dann alles mit folgenden Kommandos:

osm@osm:~$ 
  sudo aptitude update
  sudo aptitude install postgresql-8.3 postgresql-client-8.3 postgresql-contrib-8.3 \
           postgresql-server-dev-8.3 postgresql-8.3-postgis subversion cvs build-essential \
           autoconf libxml2-dev libgeos-dev libbz2-dev libpq-dev sun-java6-jre unzip
  wget http://bretth.dev.openstreetmap.org/osmosis-build/osmosis-latest.zip
  sudo unzip -d /opt osmosis-latest.zip
  sudo ln -s /opt/osmosis-* /opt/osmosis
  sudo chmod +x /opt/osmosis/bin/osmosis

Datenbank Setup

Als nächstes muss die Datenbank eingerichtet werden. Zunächst sollten in der Datei /etc/postgresql/8.3/main/postgresql.conf die Konfigurationswerte „shared_buffers“ und „checkpoint_segments“, die in der Standard-Konfiguration recht niedrig gewählt sind, erhöht werden. Sinnvolle Werte sind beispielsweise „shared_buffers=16GB“ (Standardwert: 32M) und „checkpoint_segments=16“ (Standardwert: 3).

Als nächstes wollen wir die hstore Extension herunterladen, kompilieren und installieren. Das ist selbstverständlich nur nötig, wenn nicht zuvor das „postgresql-8.3-hstore-new installiert“ Paket wurde:

osm@osm:~$
  cvs -d :pserver:anonymous@cvs.pgfoundry.org:/cvsroot/hstore-new checkout hstore-new
  cd hstore-new/

osm@osm:~/hstore-new$ 
  make
  sudo make install

Anschließend kann nun eine Datenbank angelegt werden:

osm@osm:~$ 
  sudo -u postgres createuser gis
    Soll die neue Rolle ein Superuser sein? (j/n) n
    Soll die neue Rolle Datenbanken erzeugen dürfen? (j/n) n
    Soll die neue Rolle weitere neue Rollen erzeugen dürfen? (j/n) n
  sudo -u postgres createdb -E UTF8 -O gis gis
  sudo -u postgres createlang plpgsql gis

Die Datenbank heißt nun „gis“, ebenso wie ihr Besitzer-Benutzer. Damit sich der Benutzer ohne Passwort an der Datenbank anmelden kann, muss die Datei „/etc/postgresql/8.3/main/pg_hba.conf“ wie folgt geändert werden. Anschließend muss der postgresql-Server neu gestartet werden.

# "local" is for Unix domain socket connections only
local   gis         gis                               trust
local   all         all                               ident sameuser

Als nächstes aktivieren wir die Erweiterungen für diese neu angelegte Datenbank:

osm@osm:~$ 
  sudo -u postgres psql gis </usr/share/postgresql/8.3/contrib/hstore-new.sql
  sudo -u postgres psql gis </usr/share/postgresql-8.3-postgis/lwpostgis.sql
  sudo -u postgres psql gis </usr/share/postgresql-8.3-postgis/spatial_ref_sys.sql

Mit postgresql-8.4 haben sich die Pfade geändert:

sudo -u postgres psql gis < /usr/share/postgresql/8.4/contrib/hstore.sql
sudo -u postgres psql gis < /usr/share/postgresql/8.4/contrib/postgis-1.5/postgis.sql
sudo -u postgres psql gis < /usr/share/postgresql/8.4/contrib/postgis-1.5/spatial_ref_sys.sql

Die Installation der PostGIS Erweiterung hat die beiden Tabellen „geometry_columns“ und „spatial_ref_sys“ angelegt, die jedoch noch dem postgres-Benutzer gehören. Damit alles klappt, muss der Besitzer auf unseren Benutzer „gis“ geändert werden:

osm@osm:~$ 
  echo 'ALTER TABLE geometry_columns OWNER TO gis; ALTER TABLE spatial_ref_sys OWNER TO gis;' | sudo -u postgres psql gis

Der nächste Schritt besteht im herunterladen, kompilieren und installieren des osm2pgsql Programms:

osm@osm:~$ 
  sudo apt-get -t lenny-backports install autoconf
  sudo apt-get install libtool
  sudo apt-get build-dep osm2pgsql
  svn co http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/
  cd osm2pgsql/

osm@osm:~/osm2pgsql$ 
  ./autogen.sh
  ./configure
  make
  sudo make install

  sudo -u postgres psql gis < 900913.sql

die letzte Zeile fügt die Beschreibung der Projektion „900913 Spherical Mercator“ in die „spatial_ref_sys“ Tabelle hinzu. Diese ist nötig um die Koordinaten, die osm2pgsql in die Datenbank geschrieben hat, in eine andere Projektion umrechnen zu können.

Planet-Dump

Nun sind wir bereit den Planet herunter zu laden und zu importieren:

osm@osm:~/data$ 
  wget https://planet.openstreetmap.org/planet-100526.osm.bz2.md5 https://planet.openstreetmap.org/planet-100526.osm.bz2
  md5sum -c planet-100526.osm.bz2.md5

Der Download dauert gut und gerne mal 4 Stunden, das Importieren des kompleten planet-files kann abhängig von der Ausstattung des Servers mehrere Tage bis hin zu einer ganzen Woche in Anspruch nehmen. Wer gerne etwas schneller Erfolge sehen möchte, kann zum Testen einen kleinen Planet-Extrakt der Geofabrik verwenden. Diesen Weg werde ich auch im Folgenden einschlagen. Für einen kompletten Planet-Import muss bei den nächsten Anweisungen einfach der Dateiname „berlin.osm.bz2“ durch „planet-100526.osm.bz2“ ersetzt werden.

osm@osm:~/data$ wget http://download.geofabrik.de/osm/europe/germany/berlin.osm.bz2

Da die Namen alle Tabellen durch einen prefix gekennzeichnet sind kann man diesen ändern und für den Testlauf einen anderen Datenbestand nutzen als für die eigentlichen Daten. So kann während eines langwierigen Imports schon mit der Einrichtung und den Tests des Renderers begonnen werden indem man dazu die zuvor als test angelegten Tabellen nutzt. Hierzu muss in diesem Beispiel beim Aufruf von osmosis der parameter --prefix in berlin abgeändert, und nach erfolgreichem Import wieder --prefix planet gesetzt werden. Der Renderer kann ebenfalls beliebige Tabellen über den Prefix unterscheiden, dies geschieht direkt beim Aufruf über die entsprechenden rendering scripts.

Erstmaliger Import

Wir importieren nun diese .osm.bz2-Datei in die zuvor erstellte Datenbank:

osm@osm:~/data$ osm2pgsql --create --database gis --username gis --prefix planet --slim --cache 2048 --hstore berlin.osm.bz2

Die Parameter haben dabei folgende Bedeutung:

--create: erstelle die Tabellen bevor sie gefüllt werden
--database gis: Datenbankname
--username gis: Benutzername
--prefix planet: Alle Tabellen werden mit „planet_“ beginnen, also z.B. „planet_point“
--slim: Erstelle den Node/Way/Relation Cache in der Datenbank statt im RAM. Hierdurch wird der RAM-Verbrauch gesenkt und spätere Diff-Updates möglich.
--cache 2048: Legt die Größe des Node-Cache im RAM fest. Sinnvolle Werte gehen bis ca. 8000 MB (höchste Node-ID * 8 Byte = ~6.5 GB).
--hstore: Aktiviert die hstore Spalte

Normalerweise wird osm2pgsql die Standard Style-Datei verwenden und daher zusätzlich zur hstore-Spalte eigene Spalten für wichtige Tags (z.B. amenity, highway und name) erstellen. Dies ist vorteilhaft, weil dann der Standard OSM-Mapnik-Stil damit umgehen kann, benötigt jedoch mehr Speicher. Alternativ kann der Import auch mit dem hstore-style erfolgen, welcher neben der hstore Spalte nur noch die id und die geometrie Spalte anlegt. Der hstore-style kann hier heruntergeladen werden: http://svn.toolserver.org/svnroot/mazder/planet-import/hstore.style Er wird dann über den zusätzlichen –-style Parameter an osm2pgsql übergeben.

Bezüglich des benötigten Speichers gibt es jedoch einige Verwirrung, da es scheint als ob ein kombinierter Import kleiner wäre, als einer, der nur die hstore Spalte verwendet. Die genauen Zahlen können in folgendem Mailinglisten Eintrag nachgelesen werden. Wenn hier jemand andere Zahlen aufweisen kann oder eine Erklärung hat, soll er sich bitte auf einer der OSM Mailinglisten melden. http://lists.openstreetmap.de/pipermail/devserver/2010-May/001021.html

Ein Planet-Import kann je nach Geschwindigkeit der Festplatten von 24 Stunden bis zu 5 Tagen und unter ungünstigen Umständen auch noch länger dauern (Benchmarks). Ein Import des o.g. Berlin Extraktes kann in unter 10 Minuten abgeschlossen werden.

Erster Test

Nun wird es Zeit nachzusehen, ob wir auch wirklich alle Daten in der Datenbank haben, die wir dort erwarten:

osm@osm:~/data$ psql -U gis gis
gis=> \d
               Liste der Relationen
 Schema |       Name       |   Typ   | Eigentümer
--------+------------------+---------+------------
 public | geometry_columns | Tabelle | gis
 public | planet_line      | Tabelle | gis
 public | planet_nodes     | Tabelle | gis
 public | planet_point     | Tabelle | gis
 public | planet_polygon   | Tabelle | gis
 public | planet_rels      | Tabelle | gis
 public | planet_roads     | Tabelle | gis
 public | planet_ways      | Tabelle | gis
 public | spatial_ref_sys  | Tabelle | gis
(9 Zeilen)

gis=> \d planet_point
       Tabelle »public.planet_point«
       Spalte       |   Typ    | Attribute
--------------------+----------+-----------
 osm_id             | integer  |
 access             | text     |
 addr:flats         | text     |
 addr:housenumber   | text     |
 addr:interpolation | text     |
 admin_level        | text     |
 aerialway          | text     |
 aeroway            | text     |
 amenity            | text     |
 area               | text     |
. . .
 wood               | text     |
 z_order            | integer  |
 tags               | hstore   |
 way                | geometry |
Indexe:
    »planet_point_index« gist (way)
    »planet_point_pkey« btree (osm_id)

gis=> SELECT osm_id, tags FROM planet_point LIMIT 5;
  osm_id   |                          tags
-----------+---------------------------------------------------------
 590204700 | "addr:street"=>"Schwanenallee", "addr:housenumber"=>"7"
 590204491 | "addr:street"=>"Menzelstraße", "addr:housenumber"=>"18"
 590204521 | "addr:street"=>"Menzelstraße", "addr:housenumber"=>"2a"
 590349404 | "amenity"=>"bench"
 590349407 | "amenity"=>"bench"
(5 Zeilen)

Schaut sehr gut aus.

Diff Imports

Die Diffs werden unter einer fortlaufenden Nummer als gzip komrimierte osc (OsmChange) Dateien unter https://planet.openstreetmap.org/replication/minute/ veröffentlicht. Im Schnitt kommt dort jede Minute eine Datei hinzu. Die Diff-Dateien eines bestimmten Zeitraums (z.B. ein halber Tag) werden mittels des Java-Tools Osmosis heruntergeladen, entpackt und in eine einzige osc-Datei verpackt. Diese wird dann an osm2pgsql weitergegeben, welches damit die Datenbank aktualisiert.

Da das Erstellen eines Planet-Dumps auf openstreetmap.org, das Herunterladen und Einspielen desselben einige Tage in Anspruch nehmen, muss der Diff-Import im Normalfall zunächst einige Tage Rückstand aufholen, bevor er in den Regelbetrieb übergeht und nur noch einzelne Diff-Dateien importiert.

Am Anfang besorgen wir uns das „load-next“ Script und einige andere Dateien, welches uns das Zusammenführen der verschiedenen Komponenten abnehmen:

osm@osm:~/data$ svn co https://svn.toolserver.org/svnroot/mazder/diff-import/ diffs

Der Import wird in einem Cronjob zu Beginn z.B. alle 15 Minuten gestartet. Zunächst muss er dann sicherstellen, dass kein anderer Import bereits läuft. Dann lädt Osmosis ausgehend vom vorliegenden State-File und der „maxInterval“ Einstellung in der mittels Osmosis angelegten „configuration.txt“ Diff-Dateien herunter und sendet diese an osm2pgsql. All dies wird vom „load-next“ Script erledigt.

Da die Dateien auf jedem Server an anderen Stellen liegen, müssen einige Pfade im Kopf der Datei angepasst werden. In unserem Beispiel könnte dies z.B. so aussehen:

#!/bin/bash
# loads the diffs for the interval read from configuration.txt
# may be executed every 5 minutes or so

PIDFILE=`basename $0`.pid

OSMOSIS=/opt/osmosis/bin/osmosis
OSM2PGSQL=/usr/local/bin/osm2pgsql
STYLE=/usr/local/share/osm2pgsql/default.style

# java proxy settings for osmosis
#JAVACMD_OPTIONS="-Dhttp.proxyHost=ha-proxy.esi -Dhttp.proxyPort=8080"
#export JAVACMD_OPTIONS

OSMOSISLOG=logs/osmosis.log
PSQLLOG=logs/osm2pgsql.log
EXPIRYLOG=logs/expiry.log
RUNLOG=logs/run.log

HOST=/var/run/postgresql
DB=gis
PREFIX=planet
USER=gis

Anschließend müssen wir Osmosis mitteilen, welches Datum die aktuell in der Datenbank vorhandenen Daten haben. Hierzu sollte vom Veröffentlichungsdatum des Planet-Dumps noch mindestens ein halber Tag abgezogen werden, um eine Überschneidung herbeizuführen. Da osm2pgsql nur die allerneuste Version eines jeden Elements speichert, ist dies kein Problem.

Der errechnete Zeitpunkt kann in dieses Tool eingetragen werden, welches im Gegenzug die entsprechende state-Datei liefert:

osm@osm:~/data/diffs$ wget "http://toolserver.org/~mazder/replicate-sequences/?Y=2010&m=05&d=25&H=08&i=00&s=00&stream=minute" -O state.txt

Nun kann „load-next“ zum ersten Mal ausgeführt werden. Der Fortschritt kann in den Dateien „logs/run.log“, „logs/osmosis.log“ und „logs/osm2pgsql.log“ überwacht werden:

osm@osm:~/data/diffs$ 
  ./load-next &
  tail -f logs/run.log
  tail -f logs/osm2pgsql.log

Wenn dieser erste Import erfolgreich war, ist es empfehlenswert, die Timing-Parameter anzupassen und den Script per Cron zu starten:

Es gibt zwei Stellen, an welchen das Download-Verhalten steuern kann. Im File "diffs/configuration.txt" wird angeben, wieviele Daten maximal in einem Schwung geladen und verarbeitet werden, über die Crontab wird eingestellt, wieoft nach neuen Daten gesucht werden soll.

Es hat sich bewährt, die Daten von bis zu 6 Stunden (21600 Sekunden) in einem Schwung zu laden und den Cronjob für den Anfang auf ein 15-30 Minuten Intervall zu einzustellen.

# The URL of the directory containing change files.
baseUrl=https://planet.openstreetmap.org/minute-replicate/

# Defines the maximum time interval in seconds to download in a single invocation.
# Setting to 0 disables this feature.
# 6 hours
maxInterval = 21600

Sobald die eigene Datenbank nur noch 15 bis 30 Minuten hinterher der Haupt-Datenbank ist, kann man das Cronjob-Intervall auf bis zu eine Minute senken, wenn man top-aktuell sein will. Der Wert in "diffs/configuration.txt" kann ruhig so bleiben, da osmosis nur die neuesten Daten lädt.

*/1  * * * *    /home/walter/OSM/projekte/db/diffs/load-next &

Der Cron-Job merkt es, falls sein "Vorgänger" noch aktiv ist und loggt sich einfach aus ohne sonst was zu machen.

Wie weit die eigene Datenbank hinter der Haupt Datenbank ist, kann anhand der State-Datei ermittelt werden. Dazu kann z.B. das „replag“-Tool verwendet werden:

osm@osm:~/data/diffs$ ./replag -h
2 day(s) and 14 hour(s)

Hstore Index

Um die hstore Spalte, die ja alle Tags enthält, effizient durchsuchen zu können und beispielsweise alle Punkte mit „amenity=restaurant“ oder alle Linien mit „highway=trunk“ in einem bestimmten Bereich oder auch Planet-Weit zu ermitteln, muss die hstore Spalte „tags“ mit einem GiN-Index belegt werden:

osm@osm:~$ echo '
     CREATE INDEX planet_line_tags    ON planet_line    USING GIN (tags);
     CREATE INDEX planet_point_tags   ON planet_point   USING GIN (tags);
     CREATE INDEX planet_polygon_tags ON planet_polygon USING GIN (tags);
     CREATE INDEX planet_roads_tags   ON planet_roads   USING GIN (tags);
  ' | psql -U gis gis

Hstore Abfragen

Um die neue hstore Spalte jetzt nutzen zu können, müssen die SQL Abfragen auch entsprechend formuliert werden. Exemplarisch sollen hier einige SQL-Abfragen gezeigt werden:

osm@osm:~$ psql -U gis gis

gis=> -- alle Restaurants mit allen anhängenden tags
gis=> SELECT osm_id, tags FROM planet_point WHERE (tags @> '"amenity"=>"restaurant"');
gis=>
gis=> -- die Namen aller Restaurants
gis=> SELECT tags->'name' FROM planet_point WHERE (tags @> '"amenity"=>"restaurant"') AND (tags ? 'name');
gis=>
gis=> -- die Namen aller Restaurants, die mit A anfangen
gis=> SELECT tags->'name' FROM planet_point WHERE (tags @> '"amenity"=>"restaurant"') AND (tags->'name' LIKE 'A%');
gis=>
gis=> -- Informationen über Club-Mate ausschenkende Geschäfte
gis=> SELECT osm_id, tags->'name' AS "name", tags->'drink:club-mate' AS "club-mate" FROM planet_point WHERE (tags ? 'drink:club-mate');
gis=>
gis=> -- Top-20 Tags
gis=> SELECT key, count(*) FROM
gis->   (SELECT (each(tags)).key FROM planet_point) AS stat
gis->   GROUP BY key
gis->   ORDER BY count DESC, key
gis->   LIMIT 20;

Tabellenstruktur

Nach dem Import enthält die Datenbank 9 Tabellen. Diese gliedern sich in drei Kategorien.

Geometrie-Tabellen

Für die Verwendung am wichtigsten sind drei der vier Geometrie-Tabellen:

planet_point: enthält punktformige Objekte (generiert aus Nodes, welche Tags besitzen)
planet_line: enthält linienförmige Objekte (generiert aus Ways oder Relations, welche Tags besitzen)
planet_polygon: enthält flächenförmige Objekte (generiert aus Ways oder Relations, welche Tags besitzen)

Die vierte Geometrie-Tabelle ist die:

planet_roads: enthält Linienförmige Objekte (Ways oder Relations) mit ausgewählten Tags - diese Tabelle ist für das Rendern von Kacheln auf kleinen Zoom-Stufen. Da die Tabelle z.B. keine Fußwege enthält, sind die Abfragen hierauf schneller.

Diese Tabellen enthalten eine Spalte für jeden Tag, der im osm2pgsql Import-Style genannt wurde. Zusätzlich gibt es noch einige spezielle Spalten:

osm_id: die ID des Objektes in OpenStreetMap. Da sich die Tabellen planet_line und planet_polygon sowohl aus den OSM-Ways als auch den OSM-Relations zusammensetzt, könnte es doppelte IDs geben (es gibt sowhl den Weg 1200 als auch die Relation 1200). Um dieses Problem zu umgehen, bekommen die Objekte die aus Relation erstellt wurden, eine negative ID (-1200 statt 1200).

tags: die Spalte, die durch die osm2pgsql Option --hstore erstellt wird und alle OSM-Tags enthält. Man kann auf die Werte der einzelnen Spalten mittels des hstore-Operators (tags->'name') zugreifen. WHERE-Abfragen können mittels weiterer Operatoren formuliert werden.

way: dies ist Geometrie-Spalte. Sie enthält im PostGIS-Format die Geometrie-Information. In der planet_point-Tabelle sind dies 2-Dimensionale Koordinaten, in den anderen Tabellen Linien- oder Polygon-Beschreibungen. Zur Ausgabe der Inhalte kann man z.B.: die ST_AsText-, ST_AsSVG und die ST_AsGeoJSON-Funktionen verwendet werden, wobei die letztere sich zum Weiterverarbeiten in einer Programmiersprache anbietet. Alle Funktionen und Operatoren können in der PostGIS-Referenz nachgelesen werden. Es gibt außerdem zum Filtern nach den Geometrie-Werten ein Beispiel für eine bbox-Abfrage in PHP.

z_order: ein Wert, der von osm2pgsql berechnet wird, um Flächen und Linien einfacher sortieren zu können. Bei der Berechnung des z-index wird sowohl der layer-Tag als auch die Werte der Tags highway, bridge, tunnel, railway und boundary einbezogen.

way_area: ein Wert, der von osm2pgsql berechnet wird und die Fläche beschreibt, die ein Polygon abdeckt. Wurde osm2pgsql mit der Option -l (latlon) benutzt, so ist die Flaeche in Quadrat-Grad angegeben, anderenfalls in Quadratmetern.

Rohdaten-Tabellen

Diese Tabellen enthalten die Rohdaten, welche aus dem OSM-XML gelesen wurden. Diese werden von osm2pgsql für den Diff-Import verwendet; normalerweise greift man man sehr selten direkt darauf zu. Die drei Tabellen korrespondieren zu dem OSM-Primitiven:

planet_nodes
planet_ways
planet_rels

ACHTUNG: Diese Tabellen enthalten nicht alle Daten (z.B. alle Relationen) des aktuellen Planet-Files, sondern nur diejenigen, die für den gerade aktuellen Update wichtig sind!!

PostGIS-Tabellen

Die PostGIS-Tabllen sind für den internen Gebrauch von PostGIS vorgesehen und werden zum Feststellen des Geometrie-Typs der ways-Spalten verwendet. Auch diese Tabellen benutzt man fast nie direkt:

spatial_ref_sys
geometry_columns

Links

Tiefer gehende Erklärung über verschiedene Query-Typen auf den hstore. Das hier empfohlen „@>“ Query ist hier nicht erwähnt, da es erst später von Kai „entdeckt“ wurde (englisch):

Besprechung der verschiedenen Import-Styles mit Benchmarks:

http://lists.openstreetmap.de/pipermail/devserver/2010-May/001021.html

Projekt, welches die hstore-Datenbank auf dem Wikimedia Toolserver nutzt:

Dokumentation über hstore und hstore-new (englisch)

Eine Mapnik-Karte, die ihre Daten aus o.g. Toolserver-Datenbank zieht:

Eine Weltkarte auf Deutsch und eine auf Chinesisch, die alle Bezeichnungen aus dem „name:de“- bzw. „name:zh“-Tag der hstore-Spalte entnimmt.

Zweiter Teil des Tutorials

HowTo Mapnik & Tirex

DE:HowTo minutely hstore

Contents

System

Software

Datenbank Setup

Planet-Dump

Erstmaliger Import

Erster Test

Diff Imports

Hstore Index

Hstore Abfragen

Tabellenstruktur

Geometrie-Tabellen

Rohdaten-Tabellen

PostGIS-Tabellen

Links

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

site

Tools