Alternativen zum Schema von osm2pgsql ?

Das halte ich mal für ganz übel unbrauchbar und verwerfe bis auf weiteres den Gedanken von osm2pgsql abzuschwenken. Zumal das ja an sich nun ganz gut läuft. Ein Argument dafür ist dass es das originäre Format ist, aber dagegen keine Polygone zu haben ist nicht akzeptabel.

Da gibts mittlerweile nen Knotennummernkonflikt, wenn man nicht die neueste SRTM2OSM-Version benutzt.
Ausserdem hab ich den Höhenlinienlayer nur einmalig erstellt, den brauch ich so schnell nicht wieder. Die Daten ämdern sich ja nicht mehr…
Die Grundkarte wird dagegen nach jedem Import neu gerendert.
Für den PDA muß ich allerdings alles in einem Rendern. Da wäre es blöd, wenn ich dann die Grunddaten samt Höhendaten hierfür extra nochmal importieren müsste.

Gruß,
ajoessen

Ja, irgendwie wollte das simple Schema auch nicht mehr mit osmosis 0.39 laufen. Hab meine batchdateien und Wikiseiten deshalb angepasst.

Gruß,
ajoessen

ok,
das ist eine -aus meiner Sicht- voreilige Entscheidung.

Das osm2pgsql-Verfahren nimmt dir einen Haufen Arbeit ab (z.b die Polygone zusammenzubasteln), “entscheidet” aber ganz am Anfang eines Importes, was für dich “nützlich” ist.
Das geht mit irgend welchen Templates(?). Wenn dir nun irgendwas fehlt, musst du das Template ändern und neu importieren.

Bei den Osmosis-Verfahren ist alles drin, aber nicht so schön “vorverdaut”.

Man kann eben nicht alles haben.
Aber ich bin mir sicher, dass du dein Ziel (so oder so) bestimmt erreichen wirst.

Gruss
Walter

Hast du den nen Tip, wie man in der Datenbank aus einer Multipolygon-Relation ein Polygon erzeugt?

Gruß,
ajoessen

Verwerfe ich bis auf weiteres meinte: So lang ich mit PostGIS nicht so fit bin dass ich ein Verdauungs-Views erstellen kann bleibt das erstmal weg. Andere scheinen auch das Problem zu haben wie grad am Vorposter gesehen habe.
Zumal ich damit bei Import auch nur Fehlermeldungen produziert habe. Das osm2pgsql ist zwar blöd zu installieren, für Debian gibts zwar ein Paket, aber das ist uralt und man muss selbst compilieren, aber es tuts nun erstmal.

etwa so:


select id,
       name,
       st_summary(ST_BuildArea(ST_Union(linestring))) as geom
  from (
        select rm.id, rm.name, w.linestring
          from ways w, (
                        select rm.relation_id as id,
                               rm.member_id as wayid,
                               r.tags->'name' as name
                          from relation_members rm,
                               relations r
                         where rm.member_type = 'W'
                           and rm.relation_id = 1405431
                           and rm.relation_id = r.id
                         ) rm
          where w.id = rm.wayid
       ) as foo
 group by id,name
;

und das kommt raus:


gis=# \i xxx.sql
   id    |    name    |           geom           
---------+------------+--------------------------
 1405431 | Wobbenbüll | 
                      : Polygon[BS] with 1 rings
                      :    ring 0 has 38 points
                      : 
(1 Zeile)

das st_summary weglassen, und die geometry ist da

Gruss
Walter

So einfach ist das nicht. Relationen waren da noch mein Interesse, aber wenn ich die da reinhänge, dann werden alle Member und Tags der Relation in eine Zeile (genauer: ein Array) geschrieben. Das ist sehr umständlich in Hochsprachen abzufragen und ich weiß nicht wie in der Abfrage zu machen. Hast da mal einen Tipp?

Aktueller Stand: Das Simple-Schema liegt auf dem Rechner. Alles schick, sauber normalisiert, kein Vergleich mit dem Gemurkse von osm2pgsql. Aber wie komme ich nun mal an eine Tabelle mit Polygonen? Also es werden wohl zwei Tabellen werden, wenn es sauber sein soll.
Es geht sicher los mit “create table polygons as select …” - wäre schön wenn das mal einer posten könnte. Das muss doch mal einer gemacht haben! Kann doch nicht sein dass das jeder wieder neu erfinden muss. Ich schreibs auch in meine Wiki-Seite, die ich grad angefangen hab.

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.