Alternativen zum Schema von osm2pgsql ?

Tja, die Tabelle haette Dir das osm2pgsql-Gemurkse (oder alternativ auch das imposm-Gemurkse) erzeugt; beide Programme haben komplexe Aufbauregeln fuer Multipolygone eingebaut und koennen aus einer Multipolygonrelation ein sauberes Multipolygon-Objekt machen. Wenn Du das im Postgres auf dem Simple-Schema aufbauen wirst, dann wirst Du vermutlich ziemlich alt. Hier ist eine Skizze von dem, was Du ungefaehr implementieren muesstest:

http://wiki.openstreetmap.org/wiki/Relation:multipolygon/Algorithm

Bye
Frederik

Das osm2pgsql hab ich ja auch bisher im Einsatz. Nur da komme ich an die Grenzen. Die Relations sind mir da zu kompliziert im Zugriff. Das Imposm mit sein ganze Python-Trallala was da alles fehlt und ich nicht weiß wo ich es herbekomme ist der nächste Kandidat, aber nun erst mal dieser Versuch.
Mir ist schon klar dass es nun an ein Postprocessing geht, das nicht ganz ohne ist. Aber ich weiger mich zu glauben dass das noch keiner gemacht hat, also die restlichen Tabellen aus den Daten zu erzeugen, die sind ja im Prinzip alle da. Vielleicht hilft ein Blick in die Quellen von osm2pgsql da weiter.

Soweit ich das herausgefunden habe, sind Routen-relationen in der osm2pgsql-Datenbank als zusätzliche Zeilen in planet_line mit negativer osm-ID angefügt; mit dem name-tag im Feld route_name. Multipolygone und Grenzen sind zu Polygonen in planet_polygon zusammengebaut. Wenn du noch andere Relationen brauchst, musst du dir die wohl selber aus der Tabelle planet_rels rausfischen.

Gruß,
ajoessen

Ich bin auf der Suche nach dem Enforcement-Relationen die Lula uns mal eingebrockt hat. Viele speed_cams sind eben nicht mehr im Knoten als solche getaggt, die Devices wollte ich selektieren damit ich den Tag nachholen kann. Das mit den negativen IDs kenn ich ja auch, ist ja auch bei den Polygonen ähnlich mit der negativen ID. Nur type=enforcement finde ich bei den Lines nicht, obwohl im Style von mir gewünscht (andere Types schon).
Daegegen geht das sehr einfach mit dem Simple-Schema (Datenbank so allgemein kann ich ganz gut). Deswegen heisst das wohl auch so. Überhaupt ist das Schema viel sauberer. Mit Murks bei osm2pgsql mein ich die Art wie die Daten da liegen und eben dass man alles selbst raussuchen muss, hat mal einer eine Doku dazu gesehen? Das ist ja auch klar, soll ja eigentlich nur für Mapnik sein, hab ich verstanden.
Es muss doch schon ein Skriptchen geben, was die Simple etwas aufbohrt. Ich weiger mich zu glauben dass ich das nun machen muss weil es vor mir noch keiner getan hat. Ich befürchte da muss man etwas mit Hochsprachen ran (oder stored procedures), nur mit Einfügeabfragen ist das wohl schlecht lösbar.

Es geht also um Relationen, die Punkte enthalten. Das ist wohl in der osm2pgsql-Verarbeitung so nicht vorgesehen. Das Ergebnis wäre dann auch in der polygons- oder lines-Tabelle fehl am Platze.

Dann bleibt dir also nichts anderes übrig, als aus der planet_rels und planet_nodes was zusammenzubasteln.
Die tags und Werte stehen in der Tabelle planet-rels in der Spalte tags alle hintereinander, die Knotennummern und Rollen in der Spalte members.
Die Informationen da rauszupfriemeln müsste eigentlich so ähnlich ablaufen wie die Benutzung der hstore-Spalte. nur hab ich das selber noch nie gemacht.

gruß,
ajoessen

Das hat ja bei den Lines auch nichts zu suchen.
Traffic-Enforcement beruht mit wenigen Ausnahmen auf Punkten.
In der Regel sind ‘from’, ‘device’, ‘to’ alles Punkte.

HTH
Edbert (EvanE)

Meinst du wirklich das “Simple”-Schema oder doch in Wirklichkeit das “Snapshot”-Schema? Die sind zwar “verwandt” aber dennoch unterschiedlich.

http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#PostGIS_Tasks_.28Simple_Schema.29 veraltet
http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#PostGIS_Tasks_.28Snapshot_Schema.29 aktuell

Nur damit hier Klarheit herrscht.

Gruss
Walter

Momentan ist hier pgsimple_schema_0.6.sql drauf und dann mit osmosis-latest die Daten von Berlin aus der Geofabrik zum ausprobieren hinterher. Ein schönes Schema, kann man alles schick abfragen, wenn das APIDB-Schema besser ist nehm ich das auch. Reizvoll an dem osm2pgsql war ja, dass alles schon schick aufgedröselt wurde dass man es einfach benutzen kann, aber an einige Sachen kommt man nicht so schön ran.
Hier mal ein Beispiel: Die Blitzer in Relationen lassen sich so abfragen:


select r.member_id as id, r.v as enforcement, x(n.geom) as lon, y(n.geom) as lat 
from (select t.v, m.member_id from relation_tags as t inner join relation_members as m 
on t.relation_id=m.relation_id where t.k='enforcement' and m.member_role='device') as r 
inner join nodes as n 
on r.member_id=n.id;

Die in den Nodes wie früher getaggten ja sowieso, das ist ja pillepalle. Damit ist mir das Schema pauschal mal sympatiischer, wenn es nun noch möglich wäre, die Polygone herzuleiten, die Abfrage will nicht so recht klappen. Und das soll auch gar nicht so einfach sein, Du hattest aber mal eine Abfrage in diesem Thema gepostet, das ging schon so in die Richtung.
Das muss doch hinzukriegen sein dieses geile Datenbank-Schema noch um Polygone (und später Straßen) zu erweitern, dann haben wir doch alles was gebrauchen kann!

Jetzt bin ich von osm2pgsql völlig weg. Es hat einige Zeit gedauert bis ich es kapiert habe, aber das Snapshot-Schema von osmosis scheint deutlich besser zu sein. Ich habe nun einen Kumpel drauf angesetzt dass er mir ein paar SQL-Abfragen macht um brauchbare Tabellen anzulegen. Ein paar Abfragen hat er schon fertig, die man sich bei “GitHub” runterladen kann.

Hallo ajossen,

soweit ich mitbekommen habe, sind die negativen id-Werte das Zeichen dafür, daß es die Original IDs sind. Positive IDs sind dagegen gerechnete während des DB-Imports. Siehe [1]

Noch ein Hinweis: in osm2pgsql ist bei planet_polygons die id nicht eindeutig. Eine boundary-Relation mit mehreren geschlossenen Polygonen ist so mehrfach in der Tabelle enthalten, jedesmal mit der selben negativen id. Die muß man ggfs. auch per ST_Union zusammenfassen, wie weiter oben schon angegeben.

Viele Grüße

Dietmar

[1] http://www.mail-archive.com/dev@openstreetmap.org/msg15437.html

Natürlich rede ich von Dingen, die man sich da nun selbst rausdröseln müsste. Der Vorteil von osm2pgsql besteht ja darin, dass man das Butter-und-Brot-Zeug vorgekaut bekommt. Aber wehe man will etwas was damit nicht abgedeckt wird! Da ist der sauber normalisierte osmosis-Snapshot im Vorteil.