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 
Grüße,
Marek
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.
Anbei noch ein beispiel aus meiner hauptgegend. So einen dachüberstand haben 80% der häuser. http://museen.be/bilder/museen/000052-s.jpg
gruss bernd
Hallo Bernd
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.
Edbert (EvanE)
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.
Ich weiß natürlich nicht, was “wir” mappen.
Ich bin mir sogar unsicher, wer “wir” ist
http://kamelopedia.mormo.org/index.php/WIR
aber ich mappe Gebäude und keine Dächer also Grundrisse am Erdboden
nur falls das hier ne Abstimmung werden soll …
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.
Es sprich meines Erachtens auch gar nichts dagegen, die Dachflächen zu mappen, solange diese Dachflächen des Luftbildes eben die genaueste Angabe ist, die man hat.
Ich mappe sogar Wege im Wald anhand meines GPS-Gerätes wohl wissend, dass das auch 10m daneben sein kann, da ist das mit dem Dachüberstand ja minimal.
Trotzdem werde ich natürlich die Darstellung verbessern, sobald mir bessere Werte vorliegen und diese besseren Werte können bei Häusern ja schon der anliegende Fußweg oder das Nachbarhaus sein.
ok ich komme wohl aus der “Ingenieurecke” aber überlappende Häuser oder Fußwege, die ich dann als Tunnel mappen möchte will ich eigentlich nicht haben
Keiner von uns möchte überlappende Häuser haben.
Das Problem vor dem wir nun stehen ist eine solche Abbildung der Daten dass
A. Der 2D Renderer richtig darstellt (keine Überlappung, Eingang an der Hauswand
B. 3D Renderer Daten richtig darstellt
C. Richtige 3D Erfassung der Gebäudegeometrie in einem Detaillierungsgrad der genaue Ausprägung der Dachformen ermöglicht.
Ich denke, dass ein Area “hier ist ein Gebäude in der Draufsicht” mit dem alten guten building=yes identisch sein kann. Für die Fälle wo innerhalb eines Bauwerkes keine anderen building parts vorhanden sind.
Sind diese aber vorhanden, dann kann man draüber diskutieren, ob der in dem neuem Mapnik, nach neuen Regel gerenderte Grundriss nicht aus dem Umriss der Summe der Building parts in Erdgeschoß bestehen kann.
Viele Grüße,
Marek
+1 @CADdog63: Lieber noch ungenaue Daten als gar keine. Bei Luftbildern sind oft Markisen, Überdachungen, Carports oft nicht vom eigentlichen Gebäudedach zu unterscheiden, also:
Wenn genauere Daten (Grundrisse aus Kataster o.ä. sind fast immer genauer) vorliegen, diese nehmen, ansonsten halt Luftbilder.
Eine ausschließliche Entscheidung nur Dach vs. nur Grundriss halte ich für nicht praxistauglich. Die schönsten eindeutigen Definitionen helfen nicht, wenn man sie nicht befolgen kann (oder will).
Wenn Grundriss und Dachfläche nennenswert abweichen, mag für die meisten Fälle roof:extent reichen, warum aber bei komplizierteren Architekturen nicht zwei Ebenen (oder mehr) per level mappen? Bei Gebäuden am Hang, bei 3D und bei indoor mapping kommt man auf längere Sicht sowieso nicht am Ebenenproblem vorbei.
Edit: Bei 2D-Rendering kann der Gebäudeumriss die Überlagerung solcher building-parts sein.
Volle Zustimmung, ein guter Vergleich.
Bevor wir die Bing- und Aerowest-Luftbilder hatten, konnten wir Straßen oft nur ungefähr eintragen. Trotzdem war klar, dass die Stützpunkte, über die wir unsere Wege zeichnen, auf die Straßenmitte gehören. Es hat in OSM eine lange Tradition, dass wir die Daten in dem Detailgrad eintragen, der für uns momentan erreichbar ist, und sie später nach und nach verfeinern, wenn bessere Werkzeuge zur Verfügung stehen.
Wie schon von mehreren Leuten erwähnt, ist bei Gebäuden momentan der Unterschied eher akademischer Natur. Aber hier geht es doch darum zu definieren, wie der Idealzustand aussieht, sobald wir über detaillierte Daten verfügen. Oder anders ausgedrückt: Auf welches Ziel wollen wir hinarbeiten? Da dürfen wir doch keine ungeeignete Definition formulieren, nur weil vielen Mappern momentan die technischen Möglichkeiten fehlen, Perfektion zu erreichen.
Im übrigen kann jeder Luftbildmapper die Qualität ein wenig verbessern, wenn er den Gebäudegrundriss tendenziell etwas innerhalb der Dachfläche zeichnet statt genau auf den Außenrändern. Als erste Näherung ist das schon mal nicht schlecht.
Auch wenn ich kein Freund von Importen bin, lohnt sich in diesem Zusammenhang ein Blick, welche Daten in anderen Systemen verwendet werden: Die von der LGL in Baden-Württemberg zur Verfügung gestellten Daten geben die Gebäudegrundrisse wieder, siehe die Wiki-Seite.
Und schließlich zur Frage, wie der Dachüberstand eingetragen werden soll: Ein bestimmtes Taggingschema muss nicht immer jeden Spezialfall abdecken. Mit dem Simple-3D-Schema lassen sich nur ganz grobe Formen beschreiben. Dazu passt ein Tag wie roof:extent, das für über 90% der Gebäude ausreichen dürfte. Für die schwierigeren Fälle müssen die 3D-Gurus ein ausgefeilteres Schema ausarbeiten, sei es mit Layern oder Building-Parts, die über den building-Umriss hinausragen.
Richtig! Ich bin dafür. Das ist die einzige praktikable Lösung.
Nochmal: DEr Renderer der 2D Karte rendert in diesem Fall den Grundriss des Erdgeschosses als Gebäudegrundriss.
Frage: Ist der Erdgeschoss identisch mit building=yes?
In allen anderen mir bekannten Fällen wie Brücken, Wasserdurchlässe etc. gilt:
Wenn nichts dasteht: level=0, Erdoberfläche.
Alles was darüber oder darunter ist und überschneidet, muss level ungleich 0 erhalten.
Building=yes ohne weitere Angaben ist damit Erdgeschoß, ein Dachumriss (evtl. mit gepeiltem Abzug) gilt dann bis auf Weiteres eben auch als Schätzung des Gebäudes auf level=0. Damit kann man leben, eine Luftbildauflösung von 10 cm ist halt für den Großteil der Erdoberfläche in absehbarer Zukunft illusorisch. Woanders ist man schon froh, überhaupt ein Gebäude erkennen zu können.
Wo man genauere Daten hat, kann man auch genauer mappen, siehe z.B. ein paar Uni-Gebäude in Heidelberg (http://www.openstreetmap.org/?lat=49.41756&lon=8.67439&zoom=18&layers=M). Da kann man schon eher streiten, ob ein so genaues Mapping in OSM überhaupt angestrebt werden soll.
Richtig! Und es ist auch richtig dass momentan die Sat-Bilder fast überall nicht das hergeben, worüber wir hier diskutieren.
Was passert aber, wenn wir, (z.B. zwecks indoor mapping) den Zugriff auf solche Datensätze hätten?
Früher oder später ist es soweit.
Richtig ist die Aussage: für building=yes wenn nichts dasteht gilt: level=0, sprich Erdoberfläche.
Wenn wir allerdings detailiertere Datensätze haben, soll der Renderer eben diese berücksichtigen.
In solchen fällen ist ein building=yes als ein Umriss sämtlicher Inhalte eines Objektes in der XY Ebene.
Ich habe im Abschnitt Wichtiger Hinweis mal eine Erläuterung ergänzt, warum auch die LGL-Daten veraltet und damit ggfs. heute fehlerhaft sein können. Quelle waren insbesondere einige Diskussionen im Forum und talk-de.
Ich hoffe, diese Erläuterungen bremsen einige übereifrige LGL-/Maps4BW-Abmaler.
Edbert (EvanE)
Besten Dank für die Info, das würde dann bedingen, dass building=yes definitiv den wandgrundriss abbildet, oder liege ich falsch?
gruss bernd alias der wartburgritter
Im Prinzip der Wandgrundriss am Boden, aber definitiv ist in OSM nie etwas. 
Spätestens wenn man Kataster-Daten übernehmen darf, sind das die Wandumrisse auf dem Erdboden.
Edbert (EvanE)
Ist das irgenwo im deutschsprachigen Raum schon möglich?
Wem gehören die Katasterdaten in DTL., bzw wem untersteht das Katasteramt?
