Ein guter Hinweis MetiorErgoSum. Stimmt.
Macht aber nichts. Wiki muß hier geändert werden, da es anders nicht geht, wenn wir 3D machen.
Es ist so, dass wir de Facto sehr viele Gebäude so zeichnen, wie sie auf dem Luftbild zu sehen sind und die Formulierung der Wiki eher ein frommer Wunsch ist: Alle malen Gebäudeumrisse aus Bing so ab, wie sie von oben aussehen. Inclusive Dächer der Tanstellen. Daher schlage ich vor, dass wir diese Wiki Seite umformulieren.
Wir sind halt weiter als die Katasterämter was das angeht.
Die ursprüngliche Definition folgt der Denkweise und Definition eines Gebäudegrundrisses aus der Vermessungswelt. Die dachte aber in 2D Kategorien.
Dieser Satz sagt aus, dass der Versatz durch die Luftbildaufnahme kompensiert werden soll.
Das ist meiner Meinung nach eine Selbstverständlichkeit und muss von der schwierigeren Frage getrennt werden, wie denn nun genau der Umriss definiert ist.
Ich halte es auch für den typischen 2D-Renderer für sinnvoller, das Gebäude einschließlich Gebäudeteilen über dem Erdboden zu zeichnen - denn die wenigsten 2D-Renderer wollen tatsächlich den Boden abbilden (ansonsten hätten sie keine Brücken, Tunnel etc.).
Ein Beispiel: Dieses Gebäude ist in jeder Karte, die ich bisher gesehen habe, mit dieser Form eingezeichnet. Das Gebäude steht aber in der Realität zu über einem Drittel auf Stelzen. Das heißt, ein großer Teil des Gebäudes würde bei ausschließlicher Orientierung am Erdgeschoss aus der Karte verschwinden - nur dieser Teil bliebe übrig.
Sorry für das Doppelposting, aber mir ist gerade aufgefallen, dass ich auch mit Mareks Position nicht ganz übereinstimme, sondern noch eine dritte Ansicht vertrete.
Ich stimme zwar der Definition auf Basis der Form auf Erdbodenniveau nicht zu, aber bin von deiner Einbeziehung des Dachüberstands ebenso überrascht.
Als wir fürs 3D-Mapping den Gebäudeumriss als “jede Fläche, die von einem Gebäudeteil überdeckt wird” festgelegt haben, hätte ich eher an Gebäudeteile im Sinne von building:part gedacht. Das Dach wird aber normalerweise nicht mit einem gesonderten building:part modelliert, und daher ist auch der Dachüberstand nicht als gesonderter Umriss vermerkt - sondern eher mit einem Zusatztag. (Ich glaube, du hast es einmal “roof:extent” genannt?)
Den Dachüberstand einzubeziehen hätte aus Sicht der aktuellen Praxis einige ungewöhnliche Effekte. Beispielsweise würde diese Situation
ja dazu führen, dass die Gebäudeumrisse keine gemeinsamen Knoten mehr hätten, sondern sich überlappen.
Meine Auffassung war bisher:
Gebäudeteile werden in den Gebäudeumriss einbezogen, auch wenn sie erst oberhalb des Erdbodens beginnen.
Der Dachüberstand wird aber nicht für den Gebäudeumriss berücksichtigt.
Also ich würde mich tendenziell an der Fassade orientieren, wobei es bei normalen Dachüberständen ja in den Rahmen der “Messungenauigkeit” fällt, wenn man die Dachkante vom Satellitenbild abzeichnet. Interessant finde ich die Frage von angeschlossenen Überdachungen und Carports o.ä., die aus einem weiter runtergezogenen Dach bestehen. Hier würde ich intuitiv vor Ort entscheiden, ob die überdachte Fläche frei zugänglich ist (z.B. in manchen Altstädten, z.B. weites Dach, das über den Bürgersteig ragt) oder eben nicht (Carport, oder rausgezogenes Dach für Flächen, die in direktem Zusammenhang mit einem Gebäude stehen).
Mir fällt da als konkretes Beispiel ein überdachter Vorbereich einer Lagerhalle (LKW-Terminal und Rampenbereich) ein, den ich jetzt aufgrund der Vielzahl an Verstrebungen an den Außenseiten dem Gebäude zuschlagen würde, da dieser Bereich eben an das Gebäude gebunden ist und nicht bloß ein zufällig überdachtes Areal irgendwo im Nirgenwo ist…
Edit: Viel wichtiger finde ich in den meisten Fällen die Frage, wie es mit sich verbreiternden Gebäuden aussieht. Viele historische Stadtgebäude haben ein kleines Fundament und werden nach oben breiter. Aber auch moderne Gebäude, wie das Super-C in Aachen, werfen die Frage auf, denn der sichtbare Bodenbereich des Super-C ist viel kleiner als die Dach- und Kellerbereiche (daher der Name).
Die Renderer sollen auch nicht ausschließlich den Boden (level=0) abbilden, das wäre Unfug. Sie sollen aber wissen wo der Boden ist bzw. auf welchem Level das Objekt ist. Im vorliegenden Beispiel ist das (schon im 3D-Schema) mit building:min_level=1 erreicht. Damit kann er den Fußweg unter dem Stelzenteil durchziehen, ohne über sich kreuzende ways ohne Verbindung zu stolpern. Ob man das Dach samt Überstand als building:part oder getrennt als roof modelliert, ist da gar nicht so entscheidend, Hauptsache man weiß, auf welchem Level.
Mit level=, min_level= (oder building:level oder wie auch immer) ist es egal, wie sich die Stockwerke und Dächer über- oder unterschneiden.
Da muss ich widersprechen: Ich zumindest versuche, Grundrisse ohne Dachüberstände zu zeichnen. Wenn ich mir einige der Antworten in diesem Thread ansehe, scheine ich da nicht der einzige zu sein. Und neben der klaren Aussage im Wiki es gibt auch Anleitungen wie diese hier (nach unten zum Abschnitt “Gebäude” blättern), die den Grundriss propagieren, wie er technisch üblich ist.
Dass viele Gebäude größer eingezeichnet sind, gestehe ich gern zu. Viele Gelegenheitsmapper haben sich halt nie Gedanken um dieses Detail gemacht, und außerhalb von Aerowest-Bereichen ist das auch eher eine akademische Frage. Aber ich denke, dass wir die etablierte Definition nicht einfach ändern sollten.
Zum 3D-Rendering: Solange du keine Daten zu den Maßen des Dachüberstands hast, produziert deine Methode IMHO deutlich schlechtere Daten. Nehmen wir das obige Beispielgebäude mit 10x20-m-Grundriss, 5 m Höhe und 1,5 m Dachüberstand. Bisher malen die 3D-Renderer, die ich gesehen haben, einfach ein Klötzchen auf Basis des eingetragenen Grundrisses, ohne den Dachüberstand zu zeichnen. Ist das der Grundriss inklusive Dachüberstand, hast du dem Haus (ganz grob) 450 Kubikmeter Volumen angedichtet, das es in der Realität nicht hat. Wurde dagegen der Grundriss ohne Dachüberstand eingezeichnet, fehlen (wieder ganz grob bei 0,3 Meter Dachdicke) 18 Kubikmeter, die irgendwo in der Höhe rumschweben müssten.
Sind grobe Daten zum Dachüberstand vorhanden, z.B. in Form eines Tags wie building:roof:extent = 1.5 (m), kann ein 3D-Renderer den Überhang zeichnen, indem er entweder das Dach über den eingetragenen Umriss hinausragen lässt oder das Dach auf dem eingetragenen Umriss lässt und das restliche Gebäudevolumen entsprechend nach innen zieht.
Wenn definiert ist, was der Umriss bedeutet und wie groß der Dachüberstand ist, müsste der Renderer doch mit beiden Methoden klarkommen.
Das betrifft alles nur den Dachüberstand. Für spezielle Gebäudeformen, also Tankstellendächer oder Arkaden würde ich von der strengen Regel abweichen, dass der Grundriss durch horizontales Durchschneiden in 1 m Höhe ermittelt wird. Ich finde, die Stelle aus dem deutschen Wiki trifft diesen Punkt ganz gut:
Als Grauzone bleiben noch Gebäude wie dieses Beispiel, wo eine Front wie ein Schiffsbug mit zunehmender Höhe immer weiter hinausragt. Da müssten die 3D-Weisen eine passende Taggingmethode finden.
Meine Ansicht nochmal kurz zusammengefasst für die tl;dr-Fraktion: Dachüberstände gehören nicht eingezeichnet, wir sollten für Gebäudeumrisse die Definition verwenden, wie sie momentan im deutschen Wiki steht.
Wow, hab ich ja was losgetreten … Sehr feine Diskusion, finde grad cool, dass wir keinen BigBoss haben der einfach entscheidet und alle haben zu folgen. Bin gespannt wies weitergeht …
Die ersten Gebäude in meiner Gegend habe ich ohne Luftbild mit x Verenkungen eingegeben. Dabei habe ich die Wandgrundrisse (wie im wiki beschrieben) auf dem Erdboden verwendet. Seit neuestem gibt es für meine Gegend sehr detailierte Luftfotos. Nun stimmen eben alle eingegebenen Gebäude nicht mehr mit dem Foto überein. Weiterhin kann ich jetzt alle Gebäude in meinem Mappinggebiet aufgrund des Luftbildes einzeichnen. Den Dachüberstand könnte ich schätzen. Für mich sind beide Varianten machbar.
Ich sehe sogar beide Punkte. Wenn ich ehrlich bin, kann ich mich gar nicht recht auf eine Seite schlagen …
Nun, das habe ich auch mal versucht. Die Frage ist: was macht die Mehrheit? Ich denke, sie malen ab, was sie sehen.
Wenn es funktioniert, dann aber für eine Minderheit der Sat- Aufnahmen. Selbst dann, wenn es von der einen Seite geht, ist es auf der anderen Seite eine Vermutung. Die Mehrheit der Aufnahmen ist senkrecht.
Ich habe auf jedem bewohnten Kontinent in mehreren Länder editiert, kan mann leicht überprüfen. Die Schrägaufnahmen sind eine Minderheit. Und es ist gut so: sie verursachen mehr Problme als Vorteile beim Zeichnen der Gebäudeumrisse.
Das Problem mit der momentanen Definition: “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” ist, dass sie nicht eindeutig ist. Sie gibt dem Mapper die Freiheit nach Belieben zu entscheiden, wie er ein Objekt definiert. Du selbst, MetiorErgoSum schreibst von einer Grauzone. Und es ist richtig. Wir haben in der momentanen Definition eine Grauzone.
Die kann man lösen, indem man strikt die Ansicht von oben, also die maximale Ausdehnung eines Gebäudes in der XY - Ebene als building=yes definiert. Was natürlich von der bisherigen Definition abweicht.
Nun zu dem richtigen Hinweis von Tordanik: Natürlich gibt es Dachüberstände so wie Du sie in der Skizze dargestellt hast. Meist handelt es sich dabei aber um Objekte innerhalb eines Bauwerkes, also building parts.
Das Baurecht verbietet einfach das Ableiten vom Wasser von dem eigenen Gebäude auf die Dachflächen anderer Häuser.
Sorry, da habe ich mich unpräzise ausgedrückt: das Zentrum der Sat-Aufnahmen ist natürlich fast immer senkrecht, da hast Du recht. Insbesondere die neueren Aufnahmen scheinen aus relativ geringer Höhe mit recht weitwinkligen Kameras gemacht zu werden, (klarer, bessere Farben, aber aufwändigeres Höhenmodell für die Entzerrung nötig) so daß man auf einem recht großen Teil der Aufnahme den Dachüberstand abschätzen kann.
Nun spiele ich den Advocatus diaboli und spreche gegen den von mir gemachten Vorschlag:
Irgendwann werden wir sicherlich Daten aus einer Kamera oder Videokamera in OSM zu einer Fassadentextur bearbeiten können. Ebenfalls daraus 3D Daten generieren.
Das ist nur die Frage der Zeit.
Das Erfassen der Bauwerke in voller Ausprägung einer Ansicht von oben wird zu einer Ungenauigkeit führen: Die Umrisse werden nicht mit der Fassade übereinstimmen. Deswegen entschied sich Google und fast alle Firmen die ich kenne die Dachüberstände außer Acht zu lassen. Da die Gebäudeformen allerdings aus den Luftbilder gewonnen werden - und zwar aus den Orthophotos - sind alle Fassadentexturen bei Google leicht verzerrt. Es ist auch der Grund warum Google nur statische Bilder aus vier Richtungen anbietet und kein “echtes” Modell.
Nehmen wir an, in OSM entsteht ein Tool mit dem man Umrisse durch die Bilderkennung generieren kann: Es wird nur bei Ortophotos gut funktionieren. Microsoft liefert Schrägaufnahmen weil sie kein besseres Bildmaterial haben.
Hätte man vier Blickrichtungen aus Einem Luftbild, könnte man zuverlässig ein Bauwerk generieren so, wie sie in der Erdebene ist.
Das haben wir leider nicht daher werden unsere Interprätationen der Grundrisse oft mit einem Fehler behaftet.
Ich glaube Dir schon, dass Du gut und gewissenhaft die Umrisse der Gebäude zeichnest: Ich habe mir auch Deine Arbeit angesehen und wünschte mir nur, dass die meisten so arbeiteteten. Nun ist es so, dass viele Mapper das nehmen, was sie sehen, schnell ein Umriss zeichnen und basta. Gerade um dem entgegen zu wirken schrieb ich die Seite http://wiki.openstreetmap.org/wiki/Roof_modelling.
Dort ist noch nichts über die Dachüberstände zu sehen. Es sind ja auch nicht die Elemente die sehr ins Gewicht fallen bei Luftbilder mittlerer Auflösung die man in den meisten Länder der Welt als Vorlage hat.
Trotzdem wird das zu einer Frage, wenn wir genauer werden wollen und 3D Darstellung anstreben.
Dort kann man eben mit Stockwerkangaben und building parts arbeiten. Auch kann in Zukunft ein neuer Renderer der die Stockwerke berücksichtigt, diese Elemente benutzen.
Ich versuche mich an die Grundrisse auf dem Boden zu halten. Einerseits gibt es sonst Probleme bei nierdrigen Anbauten, die dann zurückversetzt sind, was aufwendiger zu zeichen ist, andererseits sind viele Häuserzüge recht gut in einer Linie ausgerichtet was das zeichnen erleichtert. Die kann man aber nur nutzen, wenn die verschiedenen Dachüberstände ignoriert.
Es ist richtig. Es gibt den sog. Fluchtliniengesetz nach dem die Fassaden in einem Straßenzug möglichst eine Linie halten sollen.
Anderseits sind dann die meisten Dachüberstände ja auch in einer Flucht.
Kannst Du ein Beispiel dafür für weitere Diskussion aufzeigen?
Probleme - bedeutet - Mehraufwand? Das haben wir bei OSM sowieso
Es wird ja hier aktuell immer um die Geometrie des Tags building=yes diskutiert.
Gibt es denn eine einfache Variante mit zwei tags diese dachüberstandsproblem mit den aktuellen Definitionen zu lösen, ohne gerade das gesamte haus in 3D eingeben zu müssen. So etwa wie ein tag für haus und ein tag für das dach.
Es gibt roof:extent= um den Dachüberstand anzugeben.
Das macht zwar vor allem für 3D Sinn, ist aber auch unabhängig davon eine klar zuordnenbare Information.
Das Bild zeigt nebenbei ganz gut ein weiteres Problem auf, wenn man den Dachüberstand mit in den Gebäudeumriss aufnimmt: Man kann einen Eingang dann nicht mehr wie gewohnt als Node im Gebäudeumriss abbilden, ohne dadurch seine Position - und als Folge davon auch die Form des hinführenden Fußwegs, die Fläche der Straße vor dem Haus etc. - deutlich zu verfälschen.
Das sit aber die Frage des Renderers. Basierst Du auf Mapnik, es ist so.
Gehtst Du davon aus, dass die Karte 2,5 bzw 3D abgebildet wird, sieht das schon anders aus.
Hm, das war wohl ein Missverständnis. Ich rede über die Daten an sich, nicht ein Rendering.
Ein Eingangsknoten kann nicht an seiner realen Position liegen und gleichzeitig Bestandteil des Gebäudeumriss-Ways sein, wenn der Gebäudeumriss den Dachüberstand mit einschließt.
Absolut richtig.
Ich gehe davon aus dass building=yes eine maximale Ausdehnung eines Bauwerkes darstellt die nicht identisch mit dem Gebäudeumriss in Erdgeschoß ist.
Warum stelle ich in Frage Atributte (wo ich selbst an deren Entwicklung gearbeitet habe) die den Sinn haben den Dachüberstand als einen Wert anzugeben:
Es gibt viele Dachüberstände die in der Ausprägung varieeren und nichts mit dem Verlauf der Außenwand einer Gebäudewand zu tun haben.
Es sit schlichtweg unmöglich dies mit einem (oder mehreren) Werten zu beschreiben. Ein Umriß mit einem Attributt löst diese Frage.
CADog63
“Wir” sind OSM User.
Klar, wir alle mappen Gebäude. In Vorbereitung auf die Erweiterung von OSM auf 3D und daraus folgenden (möglichen) Veränderungen, habe ich mir die Art wie dei Gebäude gemappt werden, so ziemlich weltweit angesehen.
Du kannst Dir gerne meine Edits anschauen um zu sehen, wo ich alles unterwegs war.
Ich stellte fest dass außer einigen, sehr präzise denkenden und aus der Ingenieurecke kommenden User die (genau so wie ich bis vor Kurzem) versuchten exakte EG Grundrise zu zeichnen, die entschiedene Mehrheit das nachmalt, was sie von oben sieht.
Daher denke ich, dass für die Generierung einer erweiterten 3D Definition (und ich habe zu dem Kodifizierungsmeeting der in 3DSB endete eingeladen) einfach die Mehrheit der Karte als Grundlage nehmen müssen.
