Wie kann diese Fläche aus einer Standard-OSM-DB (Postgresql, PostGIS, osm2pgsql) selektiert (SELECT) werden:
Gegeben (Relation): https://www.openstreetmap.org/relation/1247582
Gesucht (Outer): https://www.openstreetmap.org/way/83292815
Guten Abend,
…unnötig, das ist Quatsch-MP…
Erläuterung.
Das MP ist für mich inhaltlich und logischer Unsinn (=es ist Quatsch!)… Das MP als “leisure=park” mit einem leeren inner sagt aus, daß die inner-Fläche nicht zum Park gehören würde. Das ist bei leisure=park vor allem bei solchen Beispielen in der Regel der logische Unsinn an der Sache, das ist falsch. Parkanlagen, mögen sie auch von einem kleinen lokalen Grafen angelegt worden sein, kann man immer als Gesamtheit um das Schloß/Herrenhaus herum betrachten und immer im Zusammenhang und Zusammenspiel aller (!!) Elemente also z.B. auch der Gewässer, die das Gebäude umschließen und die Gebäude selbst… Oftmals sind es die Gebäude oder mal Nebenbauten, die durch den Park in Szene gesetzt wurden, das ist der Grund, warum auch Gebäude mit zum Park gehören und MP’s hier in meinen Augen totaler Quatsch sind.
Beim vorliegenden Park gehört für mich auch der nördlich angrenzende Wald (Teehäuschen!!) und, die nordöstlich angrenzende Wiese, ect… hinzu, eventuell auch der westlich angrenzende Wald.
leisure=park ist für mich ein Tag, bei dem man jedes MP äußerst kritisch hinterfragen muß.
Unter anderem leisure=park ist für mich ein Tag, der ein äußerst suboptimales Rendering hat. Eine simple dunkelgrün abgesetze Linie ausschließlich als Umgrenzung ist hier besser.
Sven
ich stimme Sven zu dass die Wasserflächen in der Regel komplett zum Park gehören, wie auch Bauten im Park, aber das Hauptgebäude um das herum der Park liegt, würde ich eher nicht zum Park zählen, genauso wie dessen Innenhof. Wenn das Wasser Teil einer Verteidigungsstruktur ist auch eher nicht Park, das MP wie gezeichnet könnte Sinn machen oder ggf. das Inner ohne die Wasserflächen
Wenn ich Deine Frage richtig verstehe, dann geht es dir weniger darum, ob an dieser Stelle ein MP nötig ist, sondern wie man das MP in der Postgres-DB wiederfindet oder?
Wenn ja (habe zwar in meiner DB deine Stelle nicht drin):
a) per
select members from planet_osm_rels where id=1247582
kommst du den Outer
b) per
select * from planet_osm_polygon where osm_id=-1247582
kommst Du an die Geometrie samt aller Tags dran. Das Minus bei der ID ist kein Schreibfehler, sondern osm2pgsql scheint beim Import für jedes MP ein “neues” Objekt zu erstellen, in dem dann die gesamte Geometrie (samt Inner oder weiter Outer) steckt und solche neuen Objekte bekommen von osm2pgsql ein Minus vor die ID.
Grüße
Andreas
Edit: Schreibfehler korrigiert
Wenn du nur das outer brauchst:
SELECT 'outer' AS typ, ST_ExteriorRing(way) AS geom
FROM public.dach_polygon
WHERE osm_id = -1247582
Wenn du zusätzlich die inner brauchst:
WITH
poly AS (
SELECT ST_NumInteriorRings(way) AS "anzahl_inner", way FROM public.dach_polygon WHERE osm_id = -1247582
),
outer_ring AS (
SELECT 'outer' AS typ, ST_ExteriorRing(way) AS geom FROM poly
),
inner_rings AS (
SELECT 'inner_' || gs.x AS typ, ST_InteriorRingN(way, gs.x) AS geom
FROM poly
JOIN generate_series(1, "anzahl_inner", 1) gs(x) ON 1 = 1
)
SELECT * FROM outer_ring
UNION ALL
SELECT * FROM inner_rings
Die Tabellen liegen bei mir im public-Schema und haben den prefix “dach_” statt “planet_osm_”.
Beim osm2pgsql-Import werden die Relationsmember offenbar nicht aufgelöst und mit ihren eigenen osm_ids abgelegt. Darum findet man die outer und inner nicht getrennt in der xxx_polygon-Tabelle mit ihren eigenen osm_ids, sondern nur zusammen als 1 Polygon und dort mit der osm_id der Relation * -1.
Wie immer ohne Gewehr, aber mit Gruß und der Hoffnung, dass es funktioniert.
man kann mit osm2pgsql auch alles importieren, also auch Objekte ohne tags, dann hättest du das outer auch mit eigener id vermute ich (wenn das Multipolygonhandling das nicht verhindert speziell bei mp members, das müsste man sich ansehen), nur hast du dann auch noch viel mehr zeug was du evtl nicht brauchst.
Der Schlüssel zur Lösung liegt in der Relations-ID die als negativer Wert in die Polygon-Tabelle übernommen wird. Diesen Sachverhalt muss man kennen. In der sehr guten und umfangreichen Dokumentation (https://osm2pgsql.org/doc/manual.html) zu osm2pgsql, findet sich dazu direkt allerdings nichts. Nebenläufig wird allerdings erwähnt, dass man aus diesem Grund keine negativen IDs, zum Beispiel für eigene Daten, verwenden soll: “Osm2pgsql can only handle positive ids. It uses negative ids internally (for multipolygon geometries in the database).”
Die (eigentlich) für rein interne osm2pgsql-Zwecke reservierten Middle-Tabellen “nodes, ways, rels” (slim tables) erzeuge ich aus Platzgründen übrigens nicht.
Die Tagging-/Render-Problematik zu “leisure=park” wäre vermutlich etwas für einen gesonderten Thread.
BTW: Bei dem Objekt “Burg Hülshoff” handelt es sich übrigens um den Geburts- und Lebensort von “Annette von Droste-Hülshoff”. Ihr Gedicht “Der Knabe im Moor.” dürften vermutlich einige im Deutschunterricht besprochen haben. Ihr Bild war übrigens auf den 20-DM-Scheinen.
Danke für die Hinweise und Lösungen.