Layer Konflikte bei Treppen und Gebäuden

Ich habe heute gleich 2 Layer-Konflikte von iD angemeckert bekommen.

  1. Ein Gebäudeeingang, der unter einem auskragenden Gebäudeteil liegt. Dieses Gebäudeteil habe ich als building:part (als Teil des Gesamtgebäudes) mit layer=1 getaggt, aber wenn ich den Zuweg “darunter” zum Eingang führe, meckert iD trotzdem, vermutlich weil das Gesamtgebäude keinen layer-tag hat. Nur wenn ich das auskragende Teil als separates Gebäude mit layer=1 mappe, gibt es kein Warnung, aber das entspricht natürlich nicht der Realität.

  2. Eine Treppe, die so geführt ist, dass sie nach einer Wende über sich selbst hinweg führt. Ich habe die Treppe dazu geteilt und dem oberen Teil ein layer=1 verpasst, aber das reicht nicht, iD will da eine Brücke oder einen Tunnel haben. Beides existiert aber real nicht.

Die Warnung in beiden Fällen einfach ignorieren oder gibt es einen Trick, das zu unterbinden, den ich nicht kenne?

Vielleicht hilft es, das Stück bis zum Eingang als building_passage zu mappen, auch wenn der Weg nicht durch das Gebäude geht.
Obwohl, wenn man es genau nimmt, geht es ja im Gebäude als indoor highway=corridor weiter…
Und bei der Treppe müßte es doch ähnlich einer Wasserrutsche im Erlebnisbad funktionieren… :thinking:

Way: 1431169687 | OpenStreetMap

Die Treppe kann man ja nur über verschiedene Layerwerte abbilden…

zu 1.
Klingt imho als müsste der vom Gebäude verdeckte Wegteil mit covered=yes getaggt werden.

zu 2.
Bekomme eben beim Testen dieselbe Meldung. Ein kurzes Brücken-Treppenstück fällt mir dazu nur ein.

3 Likes

building:levels= + building:min_level= dürfte hier die bessere Lösung sein. layer sollte eigentlich auch funktionieren und zumindest den Validator ruhig stellen, aber deiner Beschreibung nach wäre das ohnehin falsch und building:min_level richtig.

Normalerweise würde ich hier alles, was nicht auf dem Boden steht, auch nicht in die normalen Gebäudeumrisse packen. Dafür muss man dann den buiding:part, der über den Weg ragt natürilch mit layer=1 versehen und zusammen mit dem Gebäude und den anderen Gebäudeteilen dann in eine type=building-Relation werfen. (wie z.B. hier). Normalerweise muss man da keinen Riesenaufwand betreiben, aber wenn man die Wege unterhalb von solchen Teilen richtig erfassen will, ist es besser, als der „Hack“, dem Gesamtgebäude ein layer=1 zu geben. Außerdem führt sonst der Eingang auch eher in den Gebäudeteil, als ins Gebäude…

Arbeite mit level=* statt layer=* bei Treppen.

2 Likes

Danke für die Hinweise!

Das Gesamtgebäude und der auskragende Teil bilden definitiv einen Baukörper. Daraus 2 Gebäude zu machen und dann wieder in einer Relation zusammenzubauen würde daher nicht die Realität abbilden und wäre m.E. dann ein “Taggen für den Editor”.

Das ist hier nicht die Lösung. Die Fehlermeldung bleibt. Aber das Mappen der Level ist trotzdem sicher sinnvoll.

Das alleine reicht auch nicht aus. Die Fehlermeldung bleibt. Aber beim Ausprobieren habe ich festgestellt, dass man lediglich den Weg und die Gebäudekante an der Schnittstelle mit einem gemeinsamen Node verbinden muss, um die Fehlermeldung zu eliminieren. Du hast mich also auf die richtige Fährte gebracht.

“Statt” reicht nicht aus, aber beides zusammen funktioniert. Es gibt bei diesem speziellen Bau zwar nur 1 Geschoss, und die zum Dach führende Treppe überkreuzt sich auf halber Höhe, aber wenn ich dem oberen Teil zusätzlich zum layer=1 noch ein level=1 mitgebe, verschwindet die Fehlermeldung.

Als nächstes werde ich die Änderungen mal speichern und dann noch mal mit Osmose + Co. checken …

Das verstehst Du falsch. Es ist ein Gebäude und ein Gebäudeteil, nicht 2 Gebäude. Das ist nicht Taggen für den Editor, denn ein Gebäude sollte ja nur den Platz beinhalten, der auf dem Boden belegt wird. Weder der unter der Erde, noch der über der Erde…

1 Like

Korrekt, und so habe ich es ja auch gemappt. Den Umriss des gesamten Baukörpers als building=* und den auskragenden Teil als building:part=*. Der building:part=* liegt dabei innerhalb des Umrisses des building=*, so wie es im Wiki beschrieben ist.

Ich weiß nicht, ob ich Dir da folgen kann - soll das heißen, dass ein auskragendes Gebäudeteil kein Gebäude ist, weil es ja keinen Platz auf dem Boden belegt? Bisher habe ich als “Footprint” eines Gebäudes immer die Position der Außenwände betrachtet, auch wenn die irgendwo mal nicht auf dem Erdreich aufstehen, und lediglich den Dachüberstand (soweit bekannt) eliminiert.

Genau das. Der Gebäudeumriss ist eigentlich nur der „Fußabdruck“. Die Erklärung ist ein wenig versteckt auf https://wiki.openstreetmap.org/wiki/Simple_3D_Buildings#Underground_parts:

Diesen Aufwand würde ich, wie gesagt, nicht für kleine Überhänge oder reine Dächer betreiben, aber auf jeden Fall, wenn ein Weg dort drunter entlangführt. Es ist vor allem auch dann interessant, wenn der Eingang unter so einem Überhang ist, denn der Eingang in ein Gebäude muss ja an der building=*-Outline und nicht nur an der building:part=*-Outline sein. Heißt: Ich nutze tunnel=building_passage auch immer nur dann, wenn von dort keine Eingänge in ein Gebäude gehen, die ich erfassen möchte.

Wenn Dir das alles zu blöd ist, kannst Du natürlich auch einfach dem Gebäude selbst ein layer=1 geben, aber das ist eben einfach nur ein Hack.
Ich wollte nicht klugscheißen, sondern erklären, wie man es eigentlich korrekt macht, denn gerade bei Gebäudeteilen, die im Untergrund sind, wird sehr deutlich, dass diese nicht Teil des Gebäudeumrisses sein können, ohne Probleme zu verursachen. Leider ist diese Methode nicht sehr verbreitet, vermutlich weil type=building-Relationen für viele die Sache zu stark verkomplizieren.

Vielen Dank für die ausführliche Darlegung. War mir in dieser Form nicht geläufig, weil ich mich mit 3D_Mapping noch nicht beschäftigt habe und nur sehr gelegentlich building:part=* mappe, die Bestandteil eines building=* sind. Ich habe auch das Erfassen eines auskragenden Gebäudeteils bisher nicht als 3D-Mapping verstanden, aber ja, es geht natürlich in die Richtung.

Sollte ich irgendwann dazu übergehen, mich intensiver mit dem Detailmapping von Gebäuden zu befassen (bisher ging es eher darum, die teilweise wild verstreuten Gebäudeumrisse von der Form und Lage her zurecht zu rücken), weiß ich jetzt auf jeden Fall, wie ich solche Objekte anzugehen habe. Deine Erläuterungen waren also nicht umsonst.

das sagt doch explizit dass man den Umriss oder footprint nehmen soll, also beides möglich ist, oder nicht?

building=* beschreibt den Umriss des Gebäudes auf dem Erdboden. Dein Erker gehört daher nicht in dieses Polygon. Der von @Nadjita beschriebene Weg ist nach dem 3D Building Schema korrekt. Die Relation brauchst du nur wenn Gebäudeteile außerhalb liegen.

das ist nicht die übliche Praxis, sonst würde man bei Gebäuden die aufgeständert sind nur die Stützen zeichnen, das habe ich noch nie gesehen in OpenStreetMap.

Die Realität ist meistens eine Mischung, Balkone und Erker werden zwar üblicherweise nicht gezeichnet wenn es sie unter nicht gibt, meistens sind die Umrisse aber sowieso nicht sehr genau, so dass man es ggf. nichtmal sagen kann

1 Like

Wie so oft ist Augenmaß angesagt. Die allein gültige Lösung für alles wird es nie geben.
Der Umriss des Gebäudes auf dem Erdboden passt für die meisten Fälle, Balkone und Erker werden nicht berücksichtigt.
Wenn man OSM mit den genauen Umrissen im Kataster vergleicht, sieht man allerdings sehr oft Überstände aus Freisitzen und dergleichen, die man aus Luftbildern nicht erkennen kann und die nicht berücksichtigt sind. Da sehe ich aber keinen Handlungsbedarf: OSM ist nicht das Kataster.
Bei Aufständerungen, Gebäudebrücken und dergleichen sollte dies aber per min_level, building:part u.ä. deutlich gemacht werden, da das vor allem in öffentlich zugänglichen Bereichen einen großen Unterschied macht.

1 Like

So sehe ich das auch.

Im Normalfall schon, aber wenn das halbe Gebäude aus einem auskragenden Bauteil besteht, lasse ich das nicht einfach weg. Also gibt es schon einen entsprechenden Bedarf an der korrekten Mappinglösung, wie von @Nadjita beschrieben. Ist ja auch kein Hexenwerk und von der Logik nachvollziehbar, man muss nur wissen, wo man es findet. Ich werde bei Gelegenheit mal einen Hinweis dazu auf der Wikiseite “Buildings” einfügen.

Richtig. So hatte ich den letzten Abschnitt

auch gemeint.

Ist das wirklich die »korrekte« Lösung auch für oberirdische Gebäudeteile?

Der Unterpunkt »Underground parts« in dem sich das »versteckt«, ist ja relativ neu und »nur« aus dieser Diskussion entstanden.

Mit der oben verlinkten Beispiel»lösung« sind dann mehrstöckige Gebäudeteile weder in 2D noch in 3D sichtbar.

Bild und Beschreibung zu building:part verstehe ich auch anders.

die f4map-demo ist aber nicht die einzige 3D-Visualisierung von OSM-Daten, m. W. aber genau die, welche bedauerlicherweise nicht mit building-part-relationen umgehen kann. die Relation ist aber genau dafür da und wird nur dann benötigt, wenn es um überstehende Gebäudeteile geht, die außerhalb des footprints liegen.

osmbuildings.org finde ich aus anderen Gründen nicht so gut gelungen, aber die relationen werden da besser gehandelt. Das sieht man am Nachbargebäude, dass in 3D korrekt dargestellt wird. Das aktuelle Gebäude wurde in osmbuildings noch nicht aktualisiert…

Ich habe da zunächst mal ein gewisses Vertrauen zu @Nadjita, der hier im Normalfall keinen Unsinn postet. Auch das beschriebene Vorgehen entbehrt nicht der notwendigen Logik. So ein Bau mit einem großen auskragenden Bauteil, unter dem ein Weg verläuft, der unter dem auskragenden Teil in einem Eingang endet, sollte sich auf diesem Wege korrekt erfassen lassen, also:

Das aufstehende Teil des Gebäudes als building, das auskragende Teil als building:part, weil es auch in der Realität kein eigenes Gebäude, sondern eben nur ein Gebäudeteil ist, dass sich an den Haupkörper des Gebäudes anschließt. Das bekommt die entsprechenden level/layer Tags. Dann kann der Weg konfliktfrei darunter verlaufen und der Eingang befindet sich am Umriss des eigentlichen Gebäudes. Und um die beiden Bauwerksteile miteinander zu verbinden, kommen die in eine entsprechende Relation.

So wird m.E. die Realität korrekt abgebildet. Wie das mit dem Rendern aussieht, weiß ich nicht, weil ich es selber noch nicht ausprobiert habe. Das entscheided aber letztendlich immer der Renderer, wie wir alle aus leidvoller Erfahrung wissen.

Ja, f4map kann mit Building-Relationen nicht umgehen, ist halt auch schon ein wenig in die Jahre gekommen. Und ob irgendeine 2D-Karte das „korrekt“ darstellt[1] ist mir auch nicht bekannt. Ich halte die 2D-Fallback-Lösung, den auskragenden Teil einfach gar nicht anzuzeigen, immer noch für besser, als ihn auf der Karte als ein Hindernis anzuzeigen, aber auch hier hat sicher jeder eine andere Vorstellung davon, wie es gerendert werden sollte. Glücklicherweise könnte man, wenn Building-Relationen mal besser unterstützt würden, einfach auswählen lassen, welches Verhalten man will.


  1. Wobei „korrekt“ hier durchaus Geschmacksfrage ist. „Normalerweise“ werden Gebäudeteile, die nicht den Boden berühren, oder unterirdisch verlaufen auf offiziellen Karten einfach gestrichelt dargestellt. Aber das ist kein Gesetz und sicher in jedem Land anders ↩︎

1 Like