3D Dächer mit Gauben

Kendzi hat schon die diskutierten Themen grob zusammengetragen - leider auf polnisch:
http://wiki.openstreetmap.org/wiki/Pl:Roof_table#Przyk.C5.82ady (Beispiele und Erwägungen)
Englische Arbeitsversion ist schon vorhanden.

Achtung: es ist ein unfertiges Arbeitsdokument unk keine ausgereifte Spezifikation. Danke im Vormab für Eure Mithilfe, insbesondere für Vorschläge was neue Dachformen betrifft!

Ich werde die deutsche Verison nächste Woche übersetzen sowie Weiteres hinzufügen.

Ich habe einige fehlende Dachformen ergänzt:
http://wiki.openstreetmap.org/wiki/DE:Roof_table#Subtype_8 und weiter sowie Überlegungen von Kendzi (der fleißig weiter code schreibt) übersetzt. Der Abschnitt “Weitere Überlegungen” ist noch ein wenig verwirrend, aber wir sind mitten in Diskussion.

Was fehlt ist eine Übersetzungstabelle zwischen den Parameter aus der 3dr Beschreibung und aus dem anderen Ansatz.

Ich habe es mittlerweile aufgegeben, alle Änderungen an der “Roof table”-Seite zu verfolgen, und das dürfte vielen anderen hier ähnlich gehen. Die Seite ist inzwischen so lang geworden, dass schon das bloße Durchlesen einige Zeit dauert, und es ist nicht gerade offensichtlich, wo sich etwas geändert hat. Dass die Inhalte auf drei unterschiedliche Sprachen verteilt sind, verbessert die Übersichtlichkeit auch nicht gerade, und es ist nicht klar, wo Diskussionen überhaupt stattfinden - soweit ich sehen kann jedenfalls weder im 3D-Forum, noch im Wiki, noch auf den großen englischsprachigen Listen.

Mein Übersetzungs-Ansatz für einige der Typen, basierend zu einem Großteil auf Wikipedia:

Type 0_0 → flat
Type 0_0 → flat (mit Gebäudeteil-Polygonen)
Type 1_0 → skillion
Type 1_1 → ?
Type 2_0 → gabled
Type 2_1 → hipped (mit Parameter für Abstand der Giebelenden vom Gebäuderand, wo einer = 0 ist)
Type 2_3 → half-hipped
Type 2_4 → hipped
Type 2_5 → pyramidal
Type 4_0 → gambrel
Type 4_1 → mansard (mit Parameter für Abstand der Giebelenden vom Gebäuderand, wo einer = 0 ist)
Type 4_2 → mansard
Type 7_1_n → sawtooth
(unbenannter 4_2-Subtyp) → gablet oder dutch_gable

Bei den Typen 8 und 9 gibt’s außer für Unterformen wie den Zwiebelturm wohl keine etablierten Begriffe, aber man könnte sich vermutlich welche ausdenken. Generell bin ich ja immer noch der Meinung, dass das Datenmodell im “fertigen” Zustand (= wenn man die allgemeine Mapper-Öffentlichkeit darauf loslässt) keine Nummern mehr zur Beschreibung der Dachformen enthalten sollte.

Mich würde auch interessieren, wie es mit dem auf deiner Seite mehrfach angeführten “OSM-Werkzeug” für das Editieren aussieht. Existiert das schon, wird daran programmiert oder ist es nur ein Konzept? Für welche der Features braucht man überhaupt ein eigenes Werkzeug und kann nicht mit JOSM-Presets (ggf. erweitert um eine 3D-Vorschau) arbeiten? Eine Nischenlösung nur für Dächer erscheint mir ehrlich gesagt nicht so sinnvoll, wenn man stattdessen an einer Verbesserung der Editoren arbeiten könnte, die auch anderen Objektarten zugute käme.

Hallo Tordanik,
es stimmt. Die Seite ist lang und wird noch länger, denn es kommen immer weitere Ideen und Lösungsansätze dazu.
Mittlerweile ist der Bedarf einer Kodifizierung offensichtlich und es ist gut dass Du´s ansprichst.
Ich kann nicht von der Community erwarten, dass sie einen Ansatz der sich entwickelt und unvollständig ist, mit großem Interesse verfolgt. Die Forum Seite ist aber eine gute Möglichkeit diejenigen zu erreeichen, die eventuell Lust haben, mitzumischen und mitzuentwickeln.

Die Inhalte werden nur auf der deutschen Seite gepflegt, nachdem ich im Vorab mit Kendzi die Sachen in der polnischen Fassung grob vorbereite.

Deine Übersetzungstabelle finde ich sehr gut. Menschennahe Attributte sind natürlich besser als abstrakte Zahlen!
Für 8 und 9 müsste man die Begriffe tatsächlich erfinden.

Die Software - Editorwerkzeug in 3D wird an der TU Lodz entwickelt (2 Leute). Kendzi implementiert weitere Formen dazu. Eigentlich sollten wir die Teile dieser Entwicklung koordiniern und uns gemeinsam ein Ziel setzen, damit wir keine doppelte Arbeit machen, denn interessante Themen gibt es genug: Ich habe sieit Langem beispielsweise nichts über OSM-4D geschrieben, die Seite wurde aber auch aktualisiert, Inhalte hinzugefügt. Dabei ist Roof Table ist nur ein Unterteil davon. Es gibt Arbeiten zur Implementierung von der Auswertung von GPS SPuren in dem 3D Gelände mit bestimmten Modellierfunktionen ( auch die TU Lodz).

Ich denke wir könnten uns mit interessierten nochmal treffen und einmal ausgiebig über Arbeiten berichten und auch diskutieren. Sozusagen Garching 2.0 :slight_smile:

Grüße,
Marek

So nun war ich doch echt gespannt und wollte mal loslegen. Da gibts ein Plugin für Josm welches das auch gleich noch anschaulich anzeigen soll. Also runtergeladen neu gestartet. Und dann dieses polige Haus eingezeichnet:
http://www.openstreetmap.org/?lat=50.999677&lon=13.798777&zoom=18&layers=M
Aber nichts passiert. Das Haus sieht mit oder ohne Dachtyp genau gleich aus im Josm. Was muss ich da noch anders machen? Ich meine ich wollte erstmal mit einfachen Gebäuden anfangen.

Außerdem habe ich noch einen interessanten Gebäudetyp gefunden:
http://www.openstreetmap.org/?lat=51.003961&lon=13.799834&zoom=18&layers=M
Diese zwei 12 Geschosser, haben einen Aufbau für den Fahrstuhl und Treppenhaus und einen Anbau vorn für die Briefkästen und den Eingang. Es gibt also drei Dachhöhen.

Hallo Viv,
ich stelle die Spez zusammen, entwickeln tut Kendzi. Möglicherweise hast Du ein Bug gefunden ,o)

Was die zweite Sache angeht, habe ich mir lange darüber den Kopf zerbrochen und habe seit gestern Abend eine (momentan nur theoretische) Lösung die die 3d Modellierung noch flexibler macht:
Ich habe nämlich Zusatzelemente:

  • Schornstein
  • Erker
  • Wintergarten
  • Balkon hinzugefügt.

Mit diesem Schema (zu 80% in der Wiki) lassen sich solche Sachen problemlos umsetzen.
Nun ist es so, dass Kendzi und seine Freunde von der TU-Lodz langsam schluchzen, wenn sie weitere Mails von mir bekommen.

Wir brauchen Unterstützung, zumal wir einen hybriden Ansatz fahren wollen, sprich:
Was einfach und parametrisierbar ist, wird parametrisch gespeichert (schneller, einfacher, weniger Fehler) die komplizierten Dachformen sollen hingegen so gehen, wie Tordanik es vorgeschlagen hat.

Hat jemand Lust mitzumachen?

Hi Viv,
die Antwort ist da:
Du hast verwendet: 3dr:type = Type 0_0
Kendzi hat die Beschreibung vor 3 Tagen vereinfacht und ich habe es noch nicht mitbekommen.
Die kurze Syntax ist: 3dr:type = 0.0

Also ohne Unterstrich und ohne Type.
Mir gefällt dies auch besser.

Die Neuerung die demnächst kommt: Basierend auf Tordaniks Übersetzungstabelle wird es für die von ihm gennante Typen egal sein welche der beiden Syntax man verwendet. Das Ergebnis wir gleich sein…

Kendzi ist auch der Meinung dass man die Seite roof table zerlegen sollte weil sie mittlerweile zu lang ist. Hat jemand von Euch Vorschläge wie?

Gruß,
Marek

Danke fürs nachschauen. Ich werde es dann morgen probieren.

Teilen kann man im Prinzip an jeder Stelle an der du den Type wechselst. Du hast dann von jeder Dachform einen typischen Vertreter oder mehrere und wenn ich das dort erkenne komme ich über einen Klick auf die Detailseiten wo dann alle Details beschrieben sind. Wird nur bei der Pflege der Übersetzungen schwieriger.

Ich habe gerade noch etwas gefunden:
http://wiki.openstreetmap.org/wiki/DE:OSM-3D
Eventuell sind die schon sehr viel weiter.
Auf jeden Fall sollten wir sie mit ins Boot holen.

Auf den ersten Blick schon - aber nur auf der Softwareebene. Auf der Definitionsebene ist leider OSM-3D etwa auf dem Stand von 1995 geblieben: sog. 2,5 D für Gebäude ( Gebäudeumriß+ Höhe als Multipliaktor) + 3D Gelände + Punkte mit Attributten als 3D.

Ich muß endlich meine alten Screenshots von 1997 von dem Projekt 3D Hamburg hochladen, wo exakt der gleiche Stand zu sehen ist.

DEr Ansatz ist verständlich: es ist überall bekannt seitdem wir es umgesetzt haben, ud leicht realisierbar:
Gelände ist da, Anzahl der Geschosse bzw. " Höhe" bekannt.

Nur ist es auf der Definitionsebene in vielen Bereichen eine Sackgasse die man schleunigst verlassen muß.

Wie schon mal vielleicht in diese Deutlichkeit noch nicht geschrieben: Wir wollen Innenräume ( Einkaufszentren usw.), Dachgeometrien, Treppenanlagen, gut modellierte Brücken und Autobahnschnecken, Bäume, archtektonische Details usw. also eine exakte Abbildung der dreidimensionalen Realität in OpenStreetMap.

Letzt endlich wollen wir Etwas, was kommerziele Datenanbieter nicht haben, weil sie es nicht haben können, weil selbst mit der teuersten Erfassungstechnik solche Modelle nur manuell machbar sind - wenn tausende Menschen mitmachen.

Eine verrückte Idee kann man meinen. OSM war es zu Anfang auch, oder?

Hallo Marek,

Beim Methodenvergleich auf der Wiki-Seite kommt das Volumenmodell im Fazit etwas zu kurz. Meiner Meinung nach eignet sich die Kombination von Volumen- und Parametermodell gut zur Reduzierung der Subtypen und intuitiverem Tagging auch und im Besonderen für größere und komplexere Gebäude. In den Beispielen wird das ja schon angedeutet.

Typ 6 ist offensichtlich für die Darstellung von Kirchenschiffen vorgesehen. Diese Gebäude sind im Allgemeinen so groß das sich auch eine Zerlegung in mehrere Gebäudeteile lohnt.
Die Typen 6.0-6.4 lassen sich z.B. auch aus mehreren Gebäudeteilen mit Typ 1.0 bzw. 2.0 zusammensetzen.
Dann wäre auch die Kombinationen mit anderen Dachtypen möglich ohne weitere Subtypen einzuführen.
Typ 6.2 ist ausserdem mit Typ 9 identisch.

Noch komplexere Subtypen die sich aus bereits definierte Grundformen zusammensetzen lassen sollten meiner Meinung nach keine eigene Gruppe bilden.

Hallo robgeb,
danke dass du dich mit diesem Theam beschäftigst. Ich bin, wie ich oft schrieb, unsicher mit einigen Themen und Definitionen und wollte von Anfan an dass dieser Bereich unter Beteiligung vieler wächst.

Fangen wir mit einfachen Sachen an:
6.2 und 9 sind nicht identisch. Bei 6.2 gibt es vier Giebelseiten die es bei 9.0 nicht gibt. 9.0 hat für jede Wand einen horizontalen Wandabschluß von dem ein Dach mit jeweils identischer Dachneigung beginnt. Den Typ 6.2 habe ich erst eingeführt, als ich merkte, dass ich mit 9.0 diverse Bauwerke nicht abdecke.

Subtype 6 Dacher bestehen in der Tat aus mehreren Eizelflächen und der Gedanke war eben die Zerlegung bei möglicht vielen Bauwerken zu vermeiden damit man mit nur einer Outline das gesamte Gebäude darstellt.
Sonst könnte man selbst beim Type 0.1 zwei Outlines 0.0 nehmen und diese übereinander legen. Dann würde man die gesamte library auf 2 Formen reduzieren können: Flachdach und Schrägdach und den Rest daraus bauen.

Natürlich ist dieser Ansatz unpraktisch. Auch eien Library ist früher oder später unpraktisch weil sie niemals in der Lage sein wird alle möglichen Dachkombinationen abzudecken. Daher ist die Frage wo man einen Strich bei der Auswahl der Grundformen zieht.

Dass die Auswahl momentan so groß ist, hängt auch mit der (von Anfang an geplanter) Definition der Tunnel in einem Gebäude. Nach dieser Definition kann man mit wenigen Parametern erstaunlich realitätsnahe Ergebnisse erreichen:

http://wiki.openstreetmap.org/wiki/File:MarekTunnelCrossingExampleVault.jpg

Hätte ich Typbeschreibung 6.X entfernt, wäre das wesentlich schwieriger.

Dein Hinweis:

Beim Methodenvergleich auf der Wiki-Seite kommt das Volumenmodell im Fazit etwas zu kurz.

ist richtig. Ich habe soeben den Abschnitt auf eine andere Wiki Seite verlegt:

http://wiki.openstreetmap.org/wiki/DE:Dachmodellierungstechniken

Dort können wir weitere Beispiele, Diskussionen , Pros und Cons sammeln. Als ich noch im Alleingang die roof table geschrieben habe fehlte mir schlichtweg die Zeit sich um alle Aspekte zu kümmern und die Seite war zu diesem Zeitpunkt sowiese sehr überladen, da wollte ich keine weiteren Sachen hinzufügen. Wenn Du möchtest, kannst Du gerne diesen Abschnitt vertiefen bzw. mit FAQ dort anfangen.

Beste Grüße,
Marek

Hier habe ich heute noch etwas interessantes entdeckt: http://latlon.org/buildings?zoom=17&lat=51.04743&lon=13.74696&layers=BT
Das sieht so aus als ob hier dei Gebäudehöhen schon erste Einflüsse hat. Leider scheint es aber nicht für alle Höhen zu funktionieren.

Es scheinen vor allem die Anzahl der Buildinglevels ausgewertet zu werden.

Guten Tag OSM Community,

ich versuche in meiner Wohngegend die Dächer in 3D zu modellieren. Es handelt sich um den Gebäudetyp 9.0. Vielleicht bin ich zu doof, aber ich verstehe die Anwendung der 3dr: Parameter nicht. Auch wird ein Parameter “alpha 1” genannt, dessen Erklärung ich nicht finde. Dann möchte ich auch wissen, ob die Dachform an das building:part oder an building=outline oder an beiden getagt wird.
Um Beispiele zu finden für erfolgreiches 3D Modellieren habe ich weltweit in der OSM Datenbank nach Mappings der beiden Entwickler gesucht und kein einziges Gebäude gefunden. Ist die Anleitung http://wiki.openstreetmap.org/wiki/DE:OSM-4D/Roof_table nur Theorie oder funktioniert das und wo finde ich dafür Beispiele?

Ich bedanke mich schon mal jetzt für Eure Hinweise.

Lieben Grüße
Stefan

Hi Stefan,
Teile von der OSM/4D Tabelle werden als S3DB Definition verwendet. Diese wird momentan in Rumänien anwendunsmäßig als JOSM PlugIn Enhanced Kendzi 3D ausgebaut. Die Form 9.0 wird dort standardmäßig verwendet, allerdings als Tagging müsste dort maßgebend die englische Version der Wiki Seite verwendet, also: http://wiki.openstreetmap.org/wiki/OSM-4D/Roof_table

User Kendzi unterstützt in seinem Tool auch die Gauben, frag ihn direkt danach.
DEr Parameter Alpha1 aus der deutshen wiki Seite bezieht sich auf die Neigung der unteren Dachfläche zur XY Ebene, wird aber momentan leider noch nicht unterstützt.

Super! Ich habe das meiner Katze erzählt, und sie ist begeistert und würde auch gerne beim Erfassen der Daten mithelfen – mit Dächern kennt sie sich ja wirklich aus. Dummerweise klappt die Steuerung des Smartphones mit ihren Krallen noch nicht so ganz, aber sobald das behoben ist … :slight_smile:

(Sorry für diese Unterbrechnung Eurer ernsten Fachdiskussion, aber ich fand Mareks “Dachdecker und Katzen”-OSM wirklich zum Kringeln!)

Nachfrage:
Auf building=outline setze ich die Parameter für das Dach in der 3dr Spezifikation, genauso wie die max Gebäudehöhe bzw. alles was an allen building=part identisch ist.

Wenn aber zum Beispiel die Dachziegel eine Gebäudeteils eine anderen Farbe hat, kann ich dann die Dachziegelfarbe (roof:colour=HEX_Farbwert) an das jeweilige Gebäudeteil das mit building:part gemappt wurde eintragen und bei der 3dr Dachspezifikation weglassen?

Siehe bitte: http://demo.f4map.com/#lat=52.4726336&lon=13.3856164&zoom=19&camera.phi=24.694

Ich habe das jetzt zm 15 mal jeweils mit veränderten Parametern hochgeladen, aber es sieht jedesmal scheisse aus. Leider muss man auf das Ergebnis ca. 24 Std. warten, bis 4map.com die Ansicht zu aktualisiert.

Dann interessiert mich auch der jeweilige Dachübergang, also das eine Gebäudedach ist Type 9.0 und im rechten Winkel daran grenzt ein Dach, welches eine kleiner Gebäudehöhe hat, aber der Dachfürst vom kleineren Dach geht in das Dach des Nachbarhaus hinein. Siehe z.B. diese Luftbildaufnahmen: http://www.businesslocationcenter.de/berlin3d-downloadportal/ und Suche nach “Tempelhofer Damm 102”.

Vorderseite und Rückseite des Gebäude hat unterschiedliche Farben. Das Dach ist aber identisch über x-Häuserblöcke. Dazwischen ist eine Tordurchfahrt mit unterschiedlichen Durchfahrtshöhen. Die Erkner sind in der obersten Etage Balkone und NICHT überdacht. … Ich bin am verzweifeln.

Hat jemand irgendwo ein Beispiel dass man sich ansehen kann. Ich habe aud der Spezifikation schon alle möglichen Kombinantionen ausprobiert. Jetzt setze ich das Dach einfach als building:part=roof oben drauf mit zusätzlich building:min_heigt=12.8 und dann noch einmal einen weiteren Umring für die building=outline. Gerade gemacht, warte mal wieder 24 Stunden auf das Ergebnis.

Ach so, dabei gleich noch eine Variannte, bei der o.g. Ansicht einfach umdrehen und auf das Tempelhofer Feld sehen. Da stehen 2 kleine Rot/Weiss gestreifte Gebäude. building=wall funktionierte nicht" Daher habe ich das alles in kleine Blöcke geschnitten und den Blöcken die Farbwerte zugewiesen. Anschließen war die Dachausrichtung an JEDEM building:part.

Also entweder ich bin zu doof oder die Erklärungen im Wiki sind nur für eine kleine Gruppe Eingeweihter zu verstehen … Ich bitte dringend die Community um Hilfe, oder strapaziere ich die Möglichkeiten des Renderers.

Herzlichen Dank und liebe Grüße
Stefan

Ich weiß ja nicht, wie Du auf dieses Schema kommtst, aber versuche es doch einfach mit http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings. Das Dach kann als eigenes building:part=yes mit min_height auf die anderen Gebäudeteile gesetzt werden.

Das Grundprinzip ist: Es gibt EIN building=* pro Gebäude, das alle Gebäudeteile (building:part=yes) umschließt. “*” ist normalerweise “yes” oder “residential” oder irgendsoetwas - nicht “outline”, weil das in der Nicht-3D-Sicht halt einfach nur das Gebäude repräsentiert. Wenn dieses Gebäude nicht in Einzelteile zerlegt wird, kann man an diesen Way alle 3D-Eigenschaften anhängen. Wenn das Gebäude aufgeteilt wird, dann enthält das Gebäude keinerlei 3D-Eigenschaften!

Bei einer Aufteilung in mehrere “building:part=yes”:
Die Gebäudeteile, wie http://www.openstreetmap.org/way/340588851 sind immer building:part=yes und KEINE eigenen Gebäude (building=apartments).
Wenn man unbedingt verschiedene Dach- und Wandfarben mappen will, kommt man um eine Aufteilung der Aufteilung der Normalgeschosse beziehungsweise der Dachflächen in einzelne Teile nicht herum. (Persönlich vermeide ich das, weil das in der Regel kaum vermeidbar blöd ausschaut und sehr schlecht wartbar ist.)

Wegen der Lizenzbedingung 2.4.3 werde ich das nicht zum Mappen nutzen.

Das Dach geht da nicht hinein, sondern es ist jeweils Teil des jeweiligen Gebäudes und haben an der Grenze den gleichen Querschnitt :wink:
Das kann man ganz einfach modellieren, wenn man das Dach entsprechend aufteilt. Siehe hier: http://demo.f4map.com/#lat=49.4549007&lon=11.0814646&zoom=21&camera.theta=32.395&camera.phi=30.653 . Zugegeben nicht ganz perfekt, aber das Prinzip ist dadurch besser erkennbar :wink:

Das Kendzi-Plugin kennst Du? Gebäude mit mehreren Teilen muss man dafür aber zu einer Relation type=building zusammenfassen (einfach building=* und alle building:part aufnehmen; Rolle ist nicht erforderlich). Damit das Objekt VOR dem Hochladen anschauen.

Was soll das bitte sein? Es gibt building=* als Gebäude oder barrier=wall als Mauer (freistehend, nicht Hauswand!).
Der Way http://www.openstreetmap.org/way/340588838 ist sinnlos, weil die Farbe doch bereits am Gebäude(teil) getagged ist…

PS: Die “Namen” der Ways http://www.openstreetmap.org/way/184424741 und http://www.openstreetmap.org/way/184424733 sind Beschreibungen, daher bitte description statt name verwenden. Außerdem ist hier landuse=grass angemessen und nicht Dorfgrün (village_green). SIehe Wiki. Alternativ wird so etwas manchmal als leisure=garden nebst access=private getagged - was ich aber wegen der garden-Definition nicht mag (Siehe auch http://forum.openstreetmap.org/viewtopic.php?id=20370 )

Ich hoffe, das hat trotz der Kürze weitergeholfen.

Herzlichen Dank ich habe das Plugin von Kendzi, aber das mit der Relation zusätzlich drum herum war mir so nicht klar.

Ich habe heute mal den Steglitzer Kreisel als erste Version in 3D gemappt. manchmal geht es wirklich schnell mit dem Rendern und manchmal dauert es Stunden. Ich denke es dauert dann lange, wenn man einen Fehler gemacht hat. Du könntest ja mal drüber schauen und mich bei Fehlern verbessern. Habe diesbezüglich sogar mit dem Liegenschaftsamt telefoniert, weil einige der Quellangaben nicht mit den Ergebnissen vor übereinstimmen.

Die anderen Kritikpunkte werde ich beherzigen, das stammt noch aus den meinen Anfängen des Mappens.

Nochmals Danke

Bitte, gerne.

Nein, das hat damit zu tun, dass F4 das Objekt maximal ein mal in 24 Stunden neu berechnet (zur Serverentlastung). Man kann also nicht immer ein Stückchen mappen und dann kurzfristig nachbessern. Manchmal haben Die aber auch Probleme mit dem Server/den Differenzdaten (siehe http://forum.openstreetmap.org/viewtopic.php?id=21489&p=12 Post #295).

Inhaltlich schwierig, weil ich das Objekt nicht kenne. Technisch schaut das ja jetzt ganz gut aus, wie man mit Kendzi sieht.
F4 wird aber voraussichtlich nicht das von Dir gewünschte Ergebnis liefern, weil die dortigen Entwickler die Eigenheit haben 3D-Eigenschaften des buildings zu berücksichtigen ODER die Eigenschaften aller building:part. Mischen geht nicht. Das heißt, dass die 3D-Eigenschaften, die am Gebäudeumring hängen in ein eigenes building:part verlagert werden müssen. Schlimmstenfalls würden dann zwei Ways deckungsgleich übereinander liegen (meistens ist das vermeidbar, wenn man das Objekt entsprechend aufteilt).