DE talk:Gebäude

Intro

Ich habe hier eine allgemeine Tutorialseite zum Zeichnen von Gebaeuden erstellt. Der Englische Wikieintrag existierte bereits nach dem Schema

• building = key:building Referenz
• buildings = Tutorial zur Benutzung

(wird auch bei highway=* / highways benutzt)

Gebaeude ist ein jetzt ein Redirect hierher, statt auf building=*

Inhalt ist so gut es geht der Konsens aus etlichen Talk-de Diskussionen. Verbesserungsvorschlaege gerne auch hier.

ToDo:

• Abschnitt zum beginnenden Indoor Mapping
• Bebilderte Schritt-fuer-Schritt Anleitung fuer Potlatch und JOSM und Merkator

FixMe:

• Links in DE:-Links aendern
• Umlaute

Tagging

Auf der Seite steht "ein Betreiber (operator=*)" - ich finde Operator etwas unpassend und habe als Übersetzung landlord=* gefunden! --Lübeck (talk) 08:17, 1 March 2013 (UTC)

Umriss, Grundriss, Grundrisslinie und Mauern am Boden: Überarbeitung des building-Tags

Durch die Diskussion auf talk-de wurde an mich herangetragen, dass es in der Kartographie üblich sei, die Mauer am Boden zur Darstellung von Gebäuden zu wählen. Außerdem sei auch in OSM der Grundriss das Ziel der Gebäudedarstellung.

Nun widerspricht dieses Ziel aber der Beschreibung von Umriss auf dieser Seite (die Englische Seite bleibt hier ungenau).

Wird die Geometrie des Gebäudes aber besonders durch solche freistehenden Formen definiert, kann auch die Grundrisslinie gezeichnet werden, also z.B. Balkone, Brücken und Gebäudeteile auf Stelzen eingeschlossen werden.

Geht man weiterhin davon aus, dass der Grundriss (also die Mauer am Boden) maßgeblich ist, so sorgt dieser Satz nun dafür, dass nicht mehr klar ist, was der Weg, der mit building=* getaggt wird, beschreibt. Für die Grundrisslinie könnte es entweder einen eigenen Weg geben oder man entwickelt ein neues Tagging für Gebäudeteile bzw. Gebäude, die nicht direkt mit dem Boden verbunden sind.

Was sollte das Ziel der Erfassung von Gebäuden in der OSM sein?

Der Renderer soll entscheiden können, ob neben der Mauer am Boden auch freie Gebäudeformen angezeigt werden sollen. So wie eine reine Dachkonstruktion dann z.B. als durchgestrichen gerendert werden kann, sollte auch ein Gebäude oder Gebäudeteil der auf Stützen konstruiert ist (hier das Amerikanische Generalkonsulat in Bremen [[1]]) durchgestrichen oder zumindest teilweise durchgestrichen gerendert werden können. Für viele Kartendarstellungen ist jedoch die Grundrisslinie (die auch freistehende Formen beinhaltet) funktionaler, da bei Bauwerken mit wenig Kontaktfläche zum Boden (z.B. reine Dachkonstruktionen) zu wenig Fläche zum Rendern der Bauwerkrelevanten Informationen bereitsteht.

Was spricht für das Beibehalten des Satzes?

• Praktische Gründe: Für mich bleibt die Frage, ob es sinnvoll ist in der OSM die Mauer am Boden als vorgabe für building=* zu behalten, denn dass an einer Stelle in einer Karte ein Gebäude steht, wird dem Kartenleser entgehen, wenn nur dessen Stützen gerendert werden. Wir werden jedoch in der OSM ohnehin beides benötigen: Grundriss und Grundrisslinie.

• Sprachliche Ungenauigkeiten 1: Zudem beschreibt der etablierte Tag building=roof eindeutig ein Bauwerk und kein Gebäude. Somit ist der Schlüssel building=* nicht eindeutig als Gebäude definiert.

• Sprachliche Ungenauigkeiten 2: Die Bedeutung von building umfasst Gebäude (z.B. Dach) und Bauwerk (z.B. Brücke). Die Übersetzung von Bauwerk ins Englische wäre jedoch structure. Siehe auch wikipedia:en:Nonbuilding_structure.

• Auf Buildings ist nicht die Rede von footprint: Zuletzt möchte ich auch noch einmal daran erinnern, dass Umriss != Grundriss ist, aber Umriss = outline und Grundriss = outline. Die korrektere Bezeichnung für Grundriss wäre meiner Ansicht nach jedoch eher footprint. Daher wäre aus meiner Sicht die bisherige Praxis in der OSM mit building=* den Umriss zu erfassen und nicht explizit den Grundriss - was auch meiner persönlichen Erfahrung in der OSM entspricht.

• Beschreibungen von Tags wie tunnel=building_passage beschreiben die Gebäudewege eindeutig als Grundrisslinie und nicht als Grundriss (siehe Tunnel#Tagging).

Weshalb ist das Problem bisher nicht aufgefallen?

Aus meiner Sicht ist der Grund folgender: Es gibt derzeit nur sehr wenige Grundrisse von Gebäuden in der OSM. Üblicherweise wurden all diese importiert und daher möglicherweise nicht ausreichend hinterfragt oder einfach nur als besser eingeschätzt. Abzeichnungen von Luftbildern waren selten (auch mangels ausreichend auflösender Luftbilder) vergleichbar genau und wurden daher in der Regeln nicht weiter mit Importen verglichen. Zudem scheinen Importe nicht durchgehend Grundrisse zu benutzen, sondern manchmal auch Grundrisslinien.

1. Lösungsversuch

• building=* bezeichnet weiterhin nicht den Grundriss eines Gebäudes, sondern die Grundrisslinie.
• Dachüberstände sind auch weiterhin nicht Teil der von building=* eingeschlossenen Fläche (siehe Grundrisslinie).
• Mauern am Boden werden nun mit outline=footprint (oder outline=bottom) getagt und üblicher Weise als Multipolygon (sofern nötig) erfasst.
• Dachumrisse könnten nun mit outline=roof getagt werden und umfassen per se Dachüberstände. Mangels Anwendung sollte jedoch davon zunächst abgesehen werden.
• Sobald ein Gebäude durch zwei unterscheidbare Umrisse/outlines repräsentiert wird, erhält der Weg mit building=* einen zusätzlichen Tag: outline=covered (oder outline=spanned oder outline=main).
• Eine Relation ordnet die Flächen (also Wege oder Multipolygone) einander zu: type=building

Ich bin gespannt auf eure Kritik und die weitere Diskussion. Sollte sich jemand ein Beispiel wünschen, bemühe ich mich um Grafik und ggf. Fotos. Eine Übersetzung für die englische Seite würde ich natürlich nachliefern. --Cracklinrain (talk) 19:30, 15 January 2014 (UTC)

Ich finde deinen Lösungsversuch prinzipiell gut, jedoch halte ich die zusätzliche Erfassung mit outline=footprint o.ä. für unnötig. Es ist aus meiner Sicht vorzuziehen, das Gebäude direkt mit building:part=* einschließlich Stockwerksinformationen zu erfassen. So ist die nötige Information vorhanden, um beliebige horizontale Querschnitte (und eben auch den Grundriss) zu errechnen. Was meinst du? --Tordanik 20:42, 15 January 2014 (UTC)

Gut. Also alles ohne min:height oder building:min_level bzw. >=0 würde damit nicht zur Grundlinie gehören. Das könnte genügen. Mir fällt gerade kein Gegenbeispiel ein. Allerdings ist es ungünstig, dass man dadurch erst einmal ein (wenn auch nich vollständiges) 3D-Modell erstellen muss, oder?--U715371 (talk) 22:00, 16 November 2014 (UTC)

POI an building=

Unter DE:Buildings#Points_of_Interest steht, dass man POIs an die Gebäude taggen soll, wenn sie die Hauptfläche des Gebäudes einnehmen. Ich halte das nicht für sinnvoll. Die Probleme sind:

• Gebäude haben häufig selber Namen, die dann dadurch nicht mehr korrekt getaggt werden können.
• Jeder Renderer der nur reine Gebäudenamen rendern möchte, wird dadurch auch POI-Namen rendern müssen.
  • OSM-Karten werden so unfreiwillig zu Werbeschleudern
• Kollisionen mit anderen Tags: z.B. Wiki-Seiten, URLs

Eine perfekte Lösung habe ich nicht, aber für besser halte ich es schlicht ein zweites Objekt zu mappen, das nur für den POI ist. Andere Mapper können dieses dann nach Bedarf anpassen. Weiterhin unklar ist dann, ob der Name von einer Mall, welche nur ein Gebäude nutzt, im Ausnahmefall der Gebäudename werden kann.

Auf der Englischen Seite gibt es diesen Abschnitt nicht. Daher würde ich die entscheidenden Passagen gerne herausnehmen und dort obiges empfehlen.--U715371 (talk) 22:11, 16 November 2014 (UTC)

Frage: Sollte bei POIs innerhalb der Grundfläche eines Gebäudes tatsächlich alle mit der vollständige Adresse getaggt werden? Oder erben die POIs die Adresse vom Gebäude worin sie liegen? Mir scheint das taggen von einer Adresse etwas überflüssig, wenn das durch die Location des POI eindeutig definiert ist. Scheinbar liefert die OSM-Suche in der Auswahlliste auch die Hausnummer von POIs wo das nicht getagt ist. Zudem führt das mehrfach-adressieren bei (mehreren) Renderern dazu, dass falls der POI-Typ nicht unterstützt wird (z.B. Ärzte), als Fallback die Hausnummer (vielfach) angezeigt wird. (wobei das speziell natürlich ein Renderer-Thema ist) Tmanyu (talk) 03:45, 7 January 2015 (UTC)

IMO: Wenn der POI eindeutig innerhalb des Gebäudeweges mit der richtigen Hausnummer liegt, muss die Hausnummer nicht dazu. Sonst ist Redundanz im Zweifel besser. Für das Rendererproblem gibt es aus meiner Sicht keine einfache Lösung. Bsp: Ein Gebäude hat Hausnummern von zwei verschiedenen Straßen, die POIs ebenfalls. --U715371 (talk) 23:47, 16 January 2015 (UTC)

Postleitzahl und Ort (in Deutschland) sinnvoll?

Die Beschreibung sagt: "auch die Postleitzahl mit anzugeben, da diese nicht über andere Daten zugeordnet werden kann."

Stimmt das überhaupt noch? Ist es wirklich sinnvoll, für jedes Gebäude die PLZ und den Ort anzugeben?

• Es sollten doch -zumindest in Deutschland - alle PLZ-Gebiete eingetragen sein (boundary=postal_code) und sich - außer für Sonderfälle - die PLZ hieraus bestimmen lassen.
• Analog beim Ort: Mit boundary=administrative sollten alle Gemeindegrenzen erfasst sein, und damit der Ort einer Adresse klar sein.

M.E. würden Straße und Hausnummer genügen - zumindest in Deutschland, wo wir einen sehr gute Datenlage haben.

Sehe ich persönlich ähnlich (zumal das Mappen von Postleitzahlen "on the ground" auch nicht so einfach ist) und hätte nichts dagegen, wenn du den Satz entfernst. Falls du lieber noch mehr Antworten willst, ist aber wohl ein Post im Forum erfolgversprechender – auf die Diskussionsseiten im Wiki schaut nur ab und zu mal jemand. --Tordanik 17:36, 31 August 2018 (UTC)

Einrichtungen im Gebäude

Man sieht häufiger - und ich bin auch häufiger so verfahren - dass POIs als zusätzliche Nodes im Gebäudeumriss erstellt werden. Zum Beispiel mehrere Geschäfte in einem Gebäude(umriss). Die würde man dann so anlegen, dass sie an den Punkten ihres jeweiligen Eingangs im Gebäude liegen. Wenn ich den Abschnitt "Einrichtungen im Gebäude" richtig interpretiere, wäre das aber nicht so gedacht und alle POIs müssten vielmehr als einzelne eigenständige Nodes innerhalb des Gebäudeumrisses liegen. Im iD Editor gibt es auch eine entsprechende Warnung wenn man ein POI in den Gebäudeumriss einfügt. Gibt es hierzu feste Vorgaben? --Gkai (talk) 23:56, 1 February 2020 (UTC)

topologisch gesehen sollte der POI sich innerhalb des Gebäudes befinden. Wenn man ihn auf den Umriss legt liegt er zwischen innen und außen. Bei vielen Dingen kann das auch praktisch eine Rolle spielen, weil dadurch unklar wird, ob sie von innen oder außen zu erreichen sind. —Dieterdreist (talk) 01:17, 2 February 2020 (UTC)

Gebäude-typ -> "Vererbung"

Da das immer wieder aufkommt, ist es vielleicht sinnvoll mal eine Vererbungspyramide von allgemein zu detailliert zu erstellen. (Ähnlich wie bei access: https://wiki.openstreetmap.org/wiki/File:Access_hierarchy_simple2.png )

also

• yes
  • residential
    • house
      • detached
    • apartments
    • [usw.]
  • industrial
  • [usw.]

oder so ähnlich? Dex2000 (talk) 15:18, 23 February 2022 (UTC)