Alternativen zum Schema von osm2pgsql ?

Zu Bildungszwecken habe ich mir seit einiger Zeit einen PostGIS-Server installiert. Darauf natürlich OSM-Daten, in meinem Fall Deutschland aus der Geofabrik, weils einfach einfach ist. Einfach vor allem durch osm2pgsql, ein Tool was mir die OSM-Daten eben in die Datenbank schreibt.
Nun sind die Senioren hier offensichtlich bei einer meine letzten Anfragen etwas irritiert gewesen und das Schema dieses Tools war nicht bekannt (hier ein Link dazu: http://wiki.openstreetmap.org/wiki/Osm2pgsql/schema ).
Dabei stellt sich mir dann die Frage: Was gibts denn noch so? Also welche Tools sind denn da noch so zu haben, mit denen man OSM-Daten auf einen SQL-Server spielt um dann Geo-Analysen damit zu machen? Also welche Alternativen hätte ich zu osm2pgsql noch so?

Die Alternative ist osmosis. Lädt die OSM-Daten auch in die Datenbank, macht aber nicht die zusätzlichen Umwandlungen, die fürs Rendern nützlich sind. So legt osm2pgsql zu jeder Routen-relation zusätzliche Wege an, mit den tags der Relation statt der einzelnen Wege (insbesondere ref- und name-tag). Ausserdem wird eine Tabelle planet_osm_roads angelegt, mit der Straßen in den niedrigen Zoomleveln schneller gerendert werden können.

Für Geo-Analysen sind diese Zusätze natürlich nicht notwendig.

Imposm kann auch Daten in die Datenbank schaufeln, hab ich aber keine Erfahrung mit.
http://wiki.openstreetmap.org/wiki/Osm2postgresql
ebenso.

Gruß,
ajoessen

Danke Dir auch für Deine Reaktion. Die beiden Tools kenn ich natürlich auch, aber mir ist so als legen die alle Daten für Mapnik bereit und müssen von daher das selbe Schema verwenden. Den Unterschied mit den Straßen kann ich so nicht erkennen, die Tabelle planet_osm_roads hab ich mit osm2pgsql auch, werd ich mir noch mal angucken.
Die Senioren hier fragten aber in einem anderen Thema hier erst mal nach, die das Schema wohl aussieht, also verwenden die wohl was anderes, daher die Frage was denn da noch möglich wäre.

Da hast du wohl was falsch mitbekommen: wambacher verwendet osmosis, und kennt deswegen das osm2pgsql-Schema nicht; ich verwende osm2pgsl, und kenne das osmosis-schema kaum.

Das osmosis-Schema ist nicht fürs Rendern mit Mapnik gedacht. Wobei es da inzwischen auch zwei Schemata git.

Gruß,
ajoessen

Danke auch Dir. Das Schema von osm2pgsql kenne ich nun so einigermaßen und es stört mich auch dass da Sache fehlen die ich gern abfragen möchte.
Ich nehme mal an das hier http://wiki.openstreetmap.org/wiki/Database_schema ist die eine Form von osmosis, was gibts da noch? Sieht auf jeden Fall schon mal umfangreicher aus und man wird da mit eigenen Programmen mehr rauslesen können kann ich mir vorstellen.
Mapnik brauch ich eh nicht, mir wäre das am liebsten was am universellsten verwendet werden kann. Was ist das die erste Wahl? Vielleicht wurde das Pro und Contra verschiedener Schemata schon in einem Artikel diskutiert?

Bei osmosis gibts aktuell das simple_schema und das snapshot_schema.
Letzteres hat folgende Tabellen:
actions
geometry_colums
nodes
relation_members
relations
schema_info
spatial_ref_sys
users
way_nodes
ways

Also so ziemlich genauso, wie die OSM-Rohdaten abgelegt sind. Polygone gibts allerdings nicht, da musst du dir aus den Relationen vom Typ boundary oder mulipolygon selber die Grenzen zusammenbauen. Dummerwesie sind die Grenzen nämlich mal so und mal so angelegt.

Gruß,
ajoessen

Nimm die fehlenden Sachen doch in das Schema auf. Das ist so trivial, dass selbst ich das hinbekommen habe. Ich wollte bspw name:de drin haben. Dazu musste ich nur die Zeile “node,way name:de text linear” in der /usr/share/osm2pgsql/default.style ergänzen

oder schau dir meinen extended_style an:
http://wiki.openstreetmap.org/wiki/User:Ajoessen/myMapnik

Zur osmosis-Datenbank gehts hier:
http://wiki.openstreetmap.org/wiki/User:Ajoessen/Osmosis
zweites Kapitel.

gruß,
ajoessen

so aus Neugier…wäre es nicht einfacher, die Höhenlinien in die OSM Datenbank zu importieren? Oder ist das wegen der Lizenz

Moin Moin,

Das simple_schema ist aus meiner Sicht obsolet; wenn schon osmosis, dann bitte snapshot-schema.
Da sind alle Tags im Hstore-Format drin (tags->‘name’, relations.tags->‘admin_level’, …)

die kleine Liste kann man noch kleiner machen, da nur folgende tabellen osm-daten enthalten:

nodes, ways, way_nodes, relations, relation_members und users.

Gruss
Walter

Danke für die Brille - das ist natürlich konfigurierbar in dieser dösigen Style-Datei, bei der ich mich immer gefragt hab wofür ich die braucht wo ich doch hinterher selber stylen will. Dank Deiner Kommentare im verlinkten Wikitext ist mir nun auch klar wofür die ist. Und die kann ich auch sinnvoll verwenden um Daten für den Mapserver vorzubereiten.

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.