In der oberen Reihe wird jeweils nur ein einziges Dach-Tag pro Gebäude gesetzt (roof:shape = gabled/hipped/half-hipped/gambrel/mansard). Dann wird einfach die Richtung der längsten Gebäudeseite als Grundlage für die Platzierung des Firsts herangezogen.
Bei der Reihe darunter ist zusätzlich ein roof:ridge:direction = SW angegeben.
Die beiden separaten Gebäude (roof:shape = flat/pyramidal) haben sowieso keine Probleme mit der Richtung. Bei allen Dächern kann außerdem die Dachhöhe per Tag eingestellt werden. Einige wenige weitere Parameter, etwa die jeweiligen Abstände der beiden Firstenden zum Gebäuderand, wären leicht einzubauen.
Bei nicht-viereckigen Gebäuden sind meine Ergebnisse noch nicht wirklich gut. Zusätzliche Nodes z.B. für building=entrance verkraftet die Software ohne Schwierigkeiten, aber bei wirklich komplexeren Formen ist für meinen derzeitigen Ansatz die Grenze dessen, wo noch etwas Ansehnliches herauszuholen ist, schnell erreicht. Außer natürlich bei explizit gemappter Geometrie wie in meinem früheren Post, die alternativ unterstützt wird.
Nebenbei bemerkt: Alle im Post genannten Tags sind einfach nur Ideen und werden natürlich ggf. geändert, wenn wir uns auf etwas geeinigt haben. Ich habe mich aber schon einmal bemüht, sprechende Namen für die Dachformen zu suchen. Generell scheint das Tagging ja noch sehr diskussionsbedürftig zu sein, so verwende ich etwa auch noch die Definition “Boden bis Dachspitze” für height.
Ist mir eigentlich auch relativ egal, wie die Höhe nun definiert ist, hauptsache sie ist eindeutig definiert. Wenn man mal bei Taginfo schaut, dann gibt es offenbar schon über 600.000 “height”-Tags in Verbindung mit einem Gebäude. Da stellt sich mir die Frage, wie viele davon nach welcher Definition getaggt sind und ob man die Definition überhaupt noch sinnvoll ändern kann. Gerade weil viele vielleicht intuitiv von der Gesamthöhe ausgehen.
Nun könnte man natürlich sagen: Wenn building:roof:shape=3dr am Gebäude steht, weiß man ja wie die Höhe gemeint ist. Allerdings werden andere Datennutzer das Tag vielleicht garnicht beachten und die Höhe als Gesamthöhe nehmen. Je nach Haus kann das Dach ja sogar mehr als die Hälfte der Höhe ausmachen.
Insgesamt eine nicht gerade zufriedenstellende Situation.
Weil bei diesem Schlüssel (und anderen, denn konsequenterweise müsste es dann ja auch building:roof:ridge:direction etc. heißen) die schiere Länge langsam unpraktisch wird. Leute, das muss noch in die Potlatch-/JOSM-Seitenspalte passen!
Außerdem: Manche der roof:-Tags werden nicht ans Gebäude selber gesetzt, sondern zumindest bei den Varianten mit expliziter Geometrie auch an Dachfirste oder andere Stellen des Dachs. Auch daher halte ich den building:-Präfix nicht für die beste Wahl.
Übrigens, bevor jemand auf die 17.000 “pitched”-Werte hinweist: Diesen Wert halte ich auf Grundlage der englischen Wikipedia-Seite für zu unscharf. Bei mir heißt das Satteldach derzeit “gabled”. Da müsste man wohl mal die Muttersprachler fragen.
Wie wäre es, wenn man den Tag an eine gezeichnete “First”-Linie (nicht ans Gebäude) setzt und damit <roof:ridge:direction = SW> “einspart”.
Dies liese sich auf Grund “der Linie-Einzeichnung” eventuell auch für <die jeweiligen Abstände der beiden Firstenden zum Gebäuderand> erweitern.
Du schlägst also eine Kombination aus der von mir schon länger implementierten Variante mit expliziter Geometrie einerseits und Dachform-Tags andererseits vor? Finde ich überlegenswert.
Im Gegensatz zum Linien-Zeichnen ist das Vergeben von Tags natürlich etwas, was man ebenso leicht in einem primitiven Editor (z.B. für Mobilgeräte ohne Maus) erledigen könnte, so dass die Hürde für die Erfassung vielleicht noch etwas geringer wäre, und die Copy&Paste-barkeit von Tags ist auch nett. Das Linienzeichnen richtet sich dann eher an den “Sesselmapper” mit Luftbildern, oder?
Zu klären wäre auch, wie man zwischen “ich habe die Dachgeometrie exakt und vollständig eingetragen” und “ich habe nur einen First als Richtungsangabe eingetragen, bitte vervollständige das Dach auf Basis des Dach-Tags” unterscheiden würde. Momentan schaue ich eben, ob irgendwelche Firstlinien o.ä. vorhanden sind - wenn ja, wird das Dach-Tagging am Gebäude ignoriert und stattdessen die von Hand gemalten Linien verwendet.
Finde ich an sich sympathisch, da es noch ein bisschen einfacher ist. Leider geht es im allgemeinen Fall nicht, denn außer an den quadratischen Häusern wird es auch an Dachformen scheitern, die nicht symmetrisch genug sind. Da ist bei denen, die ich bisher implementiert habe, keine dabei, aber 1.0 und 2.2 aus der Roof type library wären gängige Beispiele, wo es halt doch mehr als 2 Möglichkeiten gibt.
Hallo,
ich werde Freitag die Roof table um weitere Fälle ergänzen. Die Diskussion um quadratische Häuser ist insofern weniger relevant, als dass diese Fälle ziemlich selten auftreten. Viel wichtiger ist die Frage der Ausrichtung für Gebäude auf einem Grundiß der grob Buchstaben L, V, T, U, O, H ähnelt. Ich werde entsprechede (hand) Skizzen auf der Page platzieren. Der momentane Zustand der http://wiki.openstreetmap.org/wiki/DE:Roof_table ist noch alles andere als zufriedenstellend.
Ich babe über den Tag height=* nachdgedacht. Er solte doch noch lieber als Gesamthöhe eines Bauwerkes bleiben weil es schlichtweg intuitiv ist und die meisten Menschen eben so taggen würden ohne eine Spezifikation zu lesen. Ich habe auch mit Kendzi gesprochen: wir sollten die Definitionen so umkrempeln dass die beiden Seiten die es in Wiki gibt, kompatibel werden. Ich schreibe Freitag noch Einiges dazu.
Wenn du an die Dachformen nochmal rangehst, wäre es schön eine Möglichkeit von Mischformen zu haben. Zum Beispiel dieses steile Satteldach und dann in ein Flachdach übergehend.
Ich denke das Problem der quadratischen Gebäude ist eher akademischer Natur, solange es in einem Editor nicht die explizite Operation “mache quadartisch” gibt
Die Warscheinluchkeit, dass man ein Gebäude mit absolut gleichlangen Seiten erzeugt, ist nahezu null. Es recht schon, wenn eine Seite um 1 Millimeter länger ist, und schon ist das Haus für jeden Computer rechteckig.
Die quadratischen Häuser gehören also in die Informatiker Kategorie “Kühe die auf mindestens einer Seite schwarz sind”
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?
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
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.
