3D Dächer mit Gauben

chris66 · 2011-10-14T07:49:34.000Z

Jau, meine Lieblingskirche…
Ist doch in erster Näherung roof:shape=kegelförmig

marek_kleciak · 2011-10-14T08:44:55.000Z

Auch wenn kaum zu glauben: auch das wäre in OSM-4D modellierbar mit Einzelflächen. (Eine andere Sache ist, dass solches Modell nur von einem ziemlichen Profi gebaut werden kann.)
Das ganze 3dr Konzept ist für sehr einfache, wiederholbare Strukturen gedacht um die Datenmenge klein zu halten: Mit einem Parameter und wenigen zusätzlichen Attributten kann man eine 3D GEometrie beschreiben. Es ist zwar sehr mühsam in der Erfassung und dem Tagging, wenn wir aber in Zukunft ganze Stadtteile in Echtzeit in einem 3D Viewer betrachten wollen, dann lohnt sich dieser Mehraufwand schon.

Die Kirche mag ich auch: ich war schon einige Male dort um die Entwicklung auf der Baustelle zu sehen

viw · 2011-10-14T09:40:19.000Z

marek kleciak:

Hi Viw, ich kann nicht ganz folgen: “…eine Möglichkeit von Mischformen zu haben. Zum Beispiel dieses steile Satteldach und dann in ein Flachdach übergehend.”
Meinst Du mehr Beispiele wie man taggen sollte einbauen?

/
/ \

Ich hoffe man erkennt, was ich damit andeuten möchte.

marek_kleciak · 2011-10-14T10:52:04.000Z

Verstanden :), mache ich. Gruß, Marek

marek_kleciak · 2011-10-15T21:54:30.000Z

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.

marek_kleciak · 2011-10-21T09:52:22.000Z

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.

Tordanik · 2011-10-24T12:58:07.000Z

marek kleciak:

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.

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.

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

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.

marek_kleciak · 2011-10-24T13:23:06.000Z

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

Grüße,
Marek

viw · 2011-10-26T10:11:37.000Z

marek kleciak:

Ich habe eine Library mit ca. 40 Dachformen spezifiziert, dazu noch die Möglichkeit, die Dachgauben als Aufbauten auf Dächer zu platzieren.
Die Technik wurde als JOSM PlugIn von Kendzi implementiert und wird weiterentwickelt.

Ergebnis: Dach ohne Textur kann z.B. so aussehen:

http://imageshack.us/f/717/88915622.png/

Demnächst stelle ich die komplette Beschreibung auf: http://wiki.openstreetmap.org/wiki/Roof_table

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.

marek_kleciak · 2011-10-26T10:49:49.000Z

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?

marek_kleciak · 2011-10-26T19:33:55.000Z

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

viw · 2011-10-26T21:19:31.000Z

marek kleciak:

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.

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

marek kleciak:

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?

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.

viw · 2011-10-29T18:14:56.000Z

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.

marek_kleciak · 2011-10-29T20:02:27.000Z

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?

robgeb · 2011-11-16T22:29:47.000Z

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.

marek_kleciak · 2011-11-17T07:14:29.000Z

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

viw · 2011-11-20T16:49:02.000Z

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.

atpl_pilot · 2015-04-22T12:03:35.000Z

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

marek_kleciak · 2015-04-22T13:53:33.000Z

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.

Chrysopras · 2015-04-22T15:09:56.000Z

marek kleciak:

r-michael: Selbstverständlich ja, Du hast es erraten: OSM für Dachdecker und Katzen, damit sie sich auf komplizierten Dächer nicht verlieren…

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 …

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