DE:HowTo minutely hstore
 | Achtung! Veraltet! diese Information ist von Januar 2011 und vermutlich veraltet. Für aktuellere Informationen wenden Sie sich an http://switch2osm.org/ |
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.
Contents
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
 | Versionen vor osm2pgsl 0.80 brauchten zusätzlich noch das "intarray contrib module" (_int.sql), das wird in älteren Anleitungen oft noch erwähnt. Für osm2pgsql 0.80 und neuer sollte das Modul nicht geladen werden. |
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):
- http://lists.wikimedia.org/pipermail/maps-l/2010-May/000623.html
- http://lists.wikimedia.org/pipermail/maps-l/2010-May/000645.html
Besprechung der verschiedenen Import-Styles mit Benchmarks:
Projekt, welches die hstore-Datenbank auf dem Wikimedia Toolserver nutzt:
- http://wiki.openstreetmap.org/wiki/Query-to-map
- http://toolserver.org/~kolossos/qtm2/queryinmap.php?BBOX=13.5333,50.95,13.9333,51.15&name=*&key=lit&value=yes&types=lines%7Careas
Dokumentation über hstore und hstore-new (englisch)
- http://developer.postgresql.org/pgdocs/postgres/hstore.html
- http://pgfoundry.org/projects/hstore-new/
Eine Mapnik-Karte, die ihre Daten aus o.g. Toolserver-Datenbank zieht:
- http://toolserver.org/~osm/styles/?layers=B000T0FF0000F
- http://toolserver.org/~mazder/styles/surveillance/surveillance.xml
Eine Weltkarte auf Deutsch und eine auf Chinesisch, die alle Bezeichnungen aus dem „name:de“- bzw. „name:zh“-Tag der hstore-Spalte entnimmt.
- http://toolserver.org/~osm/styles/?layers=0000F0FFB000F
- http://toolserver.org/~osm/styles/?layers=0000F0FF00B0F
Zweiter Teil des Tutorials
