Münchener Frauenkirche: One feature, one OSM object?

Ja, denke ich auch.

Ich weiss nicht da die Relation type=building ist und da nicht die Unterstützung dieses Typs nicht kenne. Könnte gut sein.. das dass negative Auswirkungen hat und es dann wieder dran gemappt wird. 😉 Ich würde es so belassen.

Gruß Miche

z.B. ist diese hier als: "Seltene, ungewöhnliche Relationen" gelistet

https://wiki.openstreetmap.org/wiki/DE: … f_relation

z.B. hier wurde das Tagging wieder von der Relation wieder zurück auf die outline gemacht (Version 2) ... was ich denk auch bevorzugen würde. Aufgrund der angesprochenen Probleme

https://www.openstreetmap.org/relation/3792630/history

dktue wrote:

[...]Sollte man hier nicht alle Tags am Way entfernen, um den Grundsatz one feature, one OSM object genüge zu tun?

Viele Grüße
dktue

Die Dopplung (mit 2 x wikidata usw.) ist Mist

Aber warum den Way enttaggen, denn nebenan ist die Relation eigenschaftslos:
https://www.openstreetmap.org/relation/3061029

Afaik braucht es derartige Relationen gar nicht, auch nicht bei 3D-Detailierungen per building:part.

Also eher die Tags der Relation entfernen?

Entweder das eine oder das andere. Datenduplizierung ist immer schlecht!

Die Relation wurde vermutlich nur wegen dem 3D-mapping erstellt. Soweit ich weiß braucht es das eigentlich gar nicht...

Daher wäre ich für die übliche Lösung (die Daten an den Gebäude-Umriß zu packen).

EinKonstanzer wrote:

nur wegen dem 3D-mapping erstellt.

Denk ich auch. Das 3D Thema ist glaub ich überhaupt eingeschlafen 🤔

Die Relation ist ziemlich sicher fürs 3D-Mapping angelegt worden (auch wenn sie inzwischen auch als Wikidata-Linkziel genutzt wird). Sie dient im 3D-Bereich dazu, die Beziehung zwischen dem Gebäudeumriss und den Gebäudeteilen abzubilden, die Tags sollen aber am Gebäudeumriss bleiben.

Die Relation als solche ist aus 3D-Sicht in diesem Fall theoretisch unnötig. Sie ist aber auch nicht falsch und manche Renderer brauchen sie, um korrekt zu funktionieren. Die Relation komplett zu löschen wäre also potentiell konfliktträchtig.

Mein Vorschlag wäre, alle Tags an den Gebäudeumriss umzuziehen, nur das type=building bleibt an der Relation.

miche101 wrote:

Das 3D Thema ist glaub ich überhaupt eingeschlafen 🤔

Sehe da eigentlich keinen Grund zu der Annahme:

https://taginfo.openstreetmap.org/keys/ … chronology
https://taginfo.openstreetmap.org/keys/ … chronology

Und warum nicht KISS-Prinzip: alle Tags an den Gebäudeumriß und die überflüssige Relation löschen?

Tordanik wrote:

Sehe da eigentlich keinen Grund zu der Annahme:

https://taginfo.openstreetmap.org/keys/ … chronology
https://taginfo.openstreetmap.org/keys/ … chronology

Diese tag werden denk ich Hauptsächlich von StreetComplete Nutzer gemappt... ich hab diese Quests mitlerweile ausgeschalteten... die halten so auf. Wobei Level/roof so ungenau ist das man ich paar Jahren nochmal alles mappen muss, aber das ist ein anderes Thema.

Die wirklich gut F4Map wird schon seit 2019 nicht mehr gefixt und die anderen Karte geherschen noch nicht einmal alle "simply" Dachformen, ich denk da nur an die Zwiebel-Dach einer Kirche 🙄

Gruß Miche

Ich habe die Tags der Relation entfernt und gegebenenfalls am Way fehlende dort ergänzt (Changeset 112704420).

Hatte in "meinem" Park mit Gebäuden als einfachen geschlossenen Ways vor einigen Monaten einen "durchreisenden" 3D-Mapper,
spontane Befürchtungen waren unbegründet, der Kollege hatte sauber ergänzt
- die vorhandenen Gebäude-Ways erhalten samt Versionsgeschichte und OSM-ID
- *keine* doppelten oder sinnfreien Relationen hinzugefügt
es geht also, Im F4-Browser funktioniert es trotzdem - logisch, was will ein Renderer mit (ggf. unvollständigen) Relationen ohne Informationsinhalt, den muss er sich eh in den Einzelobjekten holen.

Wenn sollche Relationen erhalten werden zwecks Konfliktvermeidung, dann bitte bitte mit hilfreicher
note=Relation dient nur zur Zusammenfassung von [...] - alle Daten zum Objekt sind am umschließenden Way.