Zugriff auf PostGIS-DB mittels QGIS

Schau mal genau hin: bei bbox und linestring von ways steht “prüfe” dran. qgis versucht an die Infos für die beiden Geometrien ranzukommen und hat dabei Probleme. Dauert ewig, da er ALLE Objekte abfragt - und das jedesmal.
Ich habe selbst für mich noch keine vernünftige Lösung gefunden und bin mal gespannt, ob dieser Thread was bringt.
Die Postgis- und erst recht OSM-Unterstützung in QGIS ist nicht so besonders. Es sei denn, es gibt Tricks, die ich noch nicht kenne.

Frag doch mal deinen “Kumpel”, dessen spezielle Anwendung ja anscheinend funktioniert.

Gruss
walter

Ist doch genau richtig. In der OSM-DB gibt es genau 2 Tabellen mit ingesamt 3 GEOMETRIE-Spalten. Stimmt.

Gruss
walter

hi !

den habe ich schon angemailt mit der Bitte um Mitlesen - habe gerade woanders noch den Hinweis auf

gefunden. Ist das dasselbe wie

??

Gruß Jan :slight_smile:

Ich hatte euch in dem anderen Thread gewarnt!
Eine solche DB macht später ärger. Ich habe die Datenbank mit osm2pgsql eingelesen und da sind alle Geometrien angelegt. Es gibt eine Tabelle mit Straßen usw. Für den Rest gibt es dann noch eine Kompletttabelle. Leider gibt es für die neuste Version unter Windows kein hstore mehr.

ja. ab 9.1 ist hstore installiert und muß nur noch mit “create extension hstore” aktiviert werden. Du hast aber hstore drin und aktiv. schau dir mal die Spalte TAGS an, die ist vom Typ hstore.

Und so eine Query sollte bei dir Ähnliches ausgeben:


planet=# select id, tags from nodes
where tags ? 'amenity'
limit 5;

    id     |                                            tags                                            
-----------+--------------------------------------------------------------------------------------------
 602607298 | "amenity"=>"bicycle_parking"
 602607356 | "amenity"=>"parking"
 602608197 | "seats"=>"4", "colour"=>"green", "amenity"=>"bench", "backrest"=>"yes", "material"=>"wood"
 602608208 | "amenity"=>"parking", "parking"=>"surface"
 602608418 | "ele"=>"456.988892", "amenity"=>"bench", "wpt_description"=>"01-JAN-10 12:57:48"
(5 rows)

tag ? ‘amenity’ bedeutet übrigens: liste alles auf, was ein Tag “amenity” besitzt.
näheres: http://www.postgresql.org/docs/9.2/static/hstore.html

Gruss
walter

Sicher? Ich sehen in Jans Tabellen hstore-Spalten. Und wenn er gleich mal die Testquery macht, werden wir wohl auch die Tags sehen.

Nachtrag: erst denken, dann schreiben - ich glaube, du redest von hstore beim neuesten osm2pgsql unter windows. Dann sollte alles klar sein.

Sorry
walter

Wenn #18 an mich gerichtet war, dann bekomme ich ein vergleichbares Ergebnis!

Gruss Jan

PS: sogar die abgewandelte way Abfrage liefert ein Ergebnis!

jo, dann ist damit alles in Butter.

Hi,

also erst mal würde ich mir einen User unter postgresql einrichten. create user jan … mit entsprechenen Rechten, siehe psql, \h create user. Ständig als posgres arbeiten = Arbeit als Root = Arbeit als Administrator = do not.

osm2postgresql erzeugt, wie mehrfach gesagt/geschrieben, Tabellen und macht schon ein paar Auswertungen, ohne tags zu filtern.
Ansonsten, osmosis direkt, geht auch.

Wenn ich Jans Posting sehe, ist eigentlich bis auf die Flächen (logisch, osmosis) alles da. Es gibt eine Tabelle ways, in der unter linestring (so heißt das Ding in postgis → manual Postgis pdf → lesen) die Linien da sind. Jetzt muss man sich Spalten (oder weitere Tabellen) erzeugen, die die Tags in entsprechenden (Text-)Spalten haben, weil qgis mit hstore nichts anfangen kann.

alter table ways add column straße text;
update ways set straße = tags → ‘highway’ where tags ? ‘highway’;
alter table ways add column bach text;
update ways set bach = ‘Fluss’ where tags @> ‘waterway=>river’;

etc. - oder anders

Die Doku steht wie gesagt im posgis-Manual. Die Doku für hstore ist im postgresql-Manual ziemlich weit hinten (acroread suchen nach hstore).

Was du noch brauchst, wenn du direkt mit osmosis arbeitest, ist eine Tabelle für die Flächen. Postgis kann geschlossene Flächen selbst erkennen, dafür gibt es eine Funktion (->Manual). Für die Multipolygone (und admin-Grenzen) muss man sich dann selbst erst die zusammengehörigen Linien zusammensetzen (postgis) und dann die Linien gruppieren nach Zusammengehörigkeit. Am besten über ein paar temporäre Tabellen, da kann man die Zwischenergebnisse ganz gut verfolgen. Die Relationen dafür sind unter den tables ‘relations’ und ‘relation_members’ abgelegt, die sind praktisch selbsterklärend.

IIRC erzeugt osm2postgresql die Flächen-Tabelle selbst, ich weiß aber nicht mehr, wie vollständig.

Ansonsten erzeugt das Script eine Art Klassenregister. class=highway/railway/waterway etc. Ist ganz nett, stößt aber an Grenzen, beispielsweise bei der Drehbrücke in Lübeck, wenn das Gleis auf der Straße liegt.

Man kann das Script zum Eingewöhnen benutzen, das ist ratsam. Auf Dauer verbraucht es viel Zeit und letztlich schmeißt man doch einen großen Teil der Ergebnisse weg, deshalb ist es ebenso sinnvoll, sich in postgis einzulesen und die Aufstellung der Flächen selbst aufzudröseln. Etwas Erfahrung in posgis und postgresql sollte man dafür aber vorher sammeln.

Gruß, Wolfgang

Wirklich?

ein Filter wie (tags->‘highway’=‘residential’) oder (tags ? ‘building’) klappt bei mir prima - muttu nur die beiden Klammern drum machen.

Gruss
walter

mag sein, dass du eine veraltete Version von qgis einsetzt . ich fahre 1.9, meine aber, dass es unter 1.8 auch schon geklappt hat.

hi !

danke für die Rückmeldungen.

@Wolfgang: wenn ich Dich dann richtig verstehe sind das mit den fehlenden Tabellen auch die Gründe für die Lahmheit von qgis ? Aber so ganz würdest Du mir zu Anfang auch nicht von osm2postgresql abtraten. Dann hatte ich das falsch verstanden.

— gestrichen anfang —
Werde dann vielleich nochmal die DB mal mit osm2postgresql probieren und vergleichen.

Ist ja sonst auch schnell wieder erstellt.
— gestrichen ende —

Bin schon gespannt - das letzte Posting war es wohl nicht !

Gruß Jan :slight_smile:

PS: habe dann mal

SELECT * FROM nodes limit 10;

abgesetzt - da ist aber die Spalte hstore leer im Gegensatz zur Abfrage


SELECT * FROM ways limit 10;

Ist das richtig ?

Kann ich mir irgendwie nicht vorstellen!

Gibt es irgendwo eine Doku speziell für OSM (also nicht das Postgis-Handuch (englisch)), wie man nun aus den Linien (linestrings) am einfachsten Polygone und Multipolygone bastelt? Die Postgis-Funktionen sind ja doch sehr umfangreich.

Christian

ich schon :wink:

Mach mal select id,tags from nodes where tags != ‘’ limit 10 (bei != ‘’ zwei einzelne ’ , nicht ein ")

viele - genau gesagt die meisten - Nodes haben keine Tags. Aber alle Ways und Relationen sollten Tags haben.
übrigens gibt es keine Spalte mit dem Namen “hstore” in dem Snapshot-Schema. Die Spalte lautet “tags” und ist vom Typ hstore.

Gruss
walter

hab mal meine db gequält: 75.367.304 von 1.971.148.590 Nodes haben Tags. Macht 3,82 %

Ich kenne keine und benutze das hier: http://postgis.refractions.net/docs/reference.html Ist aber wohl genau das, was du nicht möchtest.

und dann geht das so:


planet=# select id,ST_AsText(st_makepolygon(linestring))
               from ways
               where ST_IsRing(linestring)
               limit 2;

    id     |                                                                                                                                                st_astext                                                                                                                                                
-----------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 136116074 | POLYGON((19.1727922 51.9233661,19.1747387 51.9232839,19.1747669 51.9231656,19.1745256 51.9225005,19.1723834 51.9227344,19.1720995 51.9228839,19.1721618 51.9232932,19.1723243 51.9232932,19.1727922 51.9233661))
 136116075 | POLYGON((19.1710499 51.9217251,19.1721557 51.9216089,19.1725706 51.9216076,19.1739396 51.9214709,19.1739101 51.9209516,19.1736491 51.9207177,19.1736491 51.9206691,19.1730433 51.9205871,19.1708155 51.9208722,19.1707288 51.9211216,19.1708125 51.9213282,19.170847 51.9215043,19.1710499 51.9217251))
(2 rows)

auf deutsch: Suche 2 (limit=2) geschlossene und saubere (ST_IsRing) Ways, konvertiere die in Polygone (ST_MakePolygon) und gib diese als lesbaren Text aus (ST_AsText) - was will man mehr.

Multipolygone sind “etwas” schwieriger, gehen aber ähnlich. :wink: Wenn wirklich Bedarf besteht , kann ich mal meine Sachen durchforsten.

Hauptproblem ist wieder, dass die OSM-Objekte - ganz besonders die Multipolygone- nicht 100% dem GIS-Standard entsprechen. Daher ist es nicht trivial, solche Operationen mit GIS-Funktionen zu machen. Irgendwie beißt sich da die Katze in den Schwanz.

Was ich aber nicht verstehe: Jan hat ganz bewußt das Snapshot-Schema genommen weil eine fertige Anwendung eines Kollegen darauf aufbaut. Dort sollten all diese Sachen eigentlich geklärt sein. Dennoch begrüße ich seine Entscheidung und helfe ihm gerne weiter.
Allerdings braucht er wohl noch etwas Praxis - auch ich hab mich am Anfang schwer getan.

Gruss
walter

Nachtrag: Ansonsten kann ich noch die “PostGIS-Bibel” vorschlagen: http://www.manning.com/obe/ allerdings ohne OSM-Bezug. DAS Standardwerk an sich.

Danke! Das sieht ja übersichtlich aus.

Das geht dann wohl in die Richtung wie in http://forum.openstreetmap.org/viewtopic.php?pid=274152#p274152 beschrieben. Daran hatte ich zuerst immer gedacht. Ich hatte einfach nicht daran gedacht, daß die meisten Flächen in OSM durch EINZELNE geschlossene Wege beschrieben werden.

Es ist gibt halt auch nicht so viele Infos im Wiki zum Thema Datenbankauswertungen. Und wenn man etwas findet, dann ist es zum osm2pgsql-Schema. Kein Wunder daß das snapshot-Schema so wenig verbreitet ist. Daher ist der Sprung von der OSM-Seite (ohne GIS-Vorkenntnisse) zu DB-Auswertungen äußert mühselig, obwohl das ganz eigentlich nicht so schwer ist.

Christian

Jo stimmt. Den Thread hatte ich schon vergessen abgeheftet :wink:

select ST_Multi(ST_BuildArea(ST_Union(linestring))) geom
           from (
                   SELECT w.linestring 
                     from relations r, relation_members rm, ways w
                    WHERE r.id = 382443 
                      AND r.id = rm.relation_id
                      AND rm.member_id = w.id 
                ) www
;

Knackpunkt ist hier der ST_Union - der macht aus den Linestrings (Way-Member der Relation) etwas. Aus dem macht ST_BuildArea eine Fläche mit eventuellen Löchern und ST_Multi dann ein Multipolygon. Und zwar ein OGC/GIS-konformes!

Das hier ist die aktuelle Version: ST_Multi( ST_BuildArea(st_geometryFromText(st_astext(ST_Union(linestring)),4326))) geom

Ich habe aus Gründen, die mir gerade nicht parat sind, einmal nach Text und dann wieder nach Geometrie konvertiert. Nur warum?
Schlecht, wenn Dokumentation ein Fremdwort ist und sich wohl die ersten Anzeichen für Altersheimer blicken lassen :wink:

Gruss
walter

Und wenn man das mal ausprobiert, wird man schnell zustimmen, daß OSM einen Flächendatentyp braucht. Man muß ja echt viel berücksichtigen, z.B. highways nicht nehmen, es sei denn es ist ‘highway=pedestrian’ oder hat ein ‘area=yes’ dran, leisure schon aber, nicht als track usw.

Gibt es eigentlich irgendwie eine schnelle Möglichkeit, mal eben eine einzelne PostGIS-Geometrie aus einer Abfrage zu visualisieren? Am besten als Plugin für pgAdmin oder halt mit copy&paste in den Webbrowser oder andere Anwendung.

Christian

Klaro. Das Filtern auf relevante Flächen hat die Auswertung natürlich vorher schon gemacht. Dies sollte ja nur ein knappes Beispiel sein.
Im Wiki für die API 0.7 ist übrigens Funkstille.

Qgis wäre meine 1 Wahl - klappt aber nicht für ad-hoc queries :frowning:
2. Wahl: openJump allerdings bin ich mit der Gui nicht so richtig warm geworden.
eventuell geht es damit.

Gruss
walter

OpenDump-Tutorial: http://static.openjump.de/media/documentation/extern/OpenJUMP151_TutorialDeEnXP.pdf

Gruß Jan :slight_smile:

Unter [1] habe ich mit Netzwolfs Hilfe eine entsprechende Seite mit Openlayers gebastelt. Bitte die Hinweise unter [2] (Format, Projektion) beachten.

Christian

[1] http://osm.duschmarke.de/wkt.html
[2] http://wiki.openstreetmap.org/wiki/User:Brogo#Darstellung_von_WKT-Elementen