DE talk:OSM-4D/Roof table

Aufteilung auf meherere Seiten

von der Seite:

Da die Seite sehr umfangreich geworden ist, findet demnächst ein Umzug der Subteile der Dächer auf separate Seiten statt.

Ich finde das ist nicht notwendig und macht das ganze nur unübersichtlicher... --Andi (talk) 10:36, 7 February 2013 (UTC)

'-' oder '_' ?

Der S3DB tag für 'half-hipped' verwendet '-' als Wortverknüpfung. Es wäre gut die OSM-4D Tag-Translations dahingehend zu verändern. Ich würde die 90 half_hipped (gegen 2200 half-hipped) demnächst umtaggen wenn es keine Einwände gibt. --j3d (talk) 00:51, 24 October 2013 (UTC)

Ich habe das im Forum angesprochen und bin für eine konsequente Änderung aller Werte mit "-" statt "_": https://forum.openstreetmap.org/viewtopic.php?pid=756819#p756819 --Geri-oc (talk) 18:24, 26 July 2019 (UTC)

3dr:direction=begin|end

Nur in den Skizzen bzw. zwischen den Zeilen kann ich die Bedeutung von 3dr:direction=begin|end erkennen. Sehe ich das richtig: Start- und End-Punkt zeigen als Vektor die Richtung des Dachfürsts an? Die Lage des Fürsts wird dabei nicht bestimmt; begin und end sind entsprechend austauschbar (der Vektor ist insofern ohne Richtung). An anderer Stelle wird eher suggeriert, dass der Tiefste Punkt eines Daches mit "begin" zu taggen ist.

Ich komme nur deshalb auf dieses Tag zurück, da roof:direction=NE von kenz3d anders gedeutet wird als von der F4-Map. Am liebsten würde ich einfach den Fürst einzeichnen...

Konkret geht es um ein Gebäude mit L-förmigen Grundriss und Satteldach (gabled), wobei das Dach über dem Vorbau (der zur L-Form führt) weiter heruntergezogen ist (Typ 3.0).

--RalfG (talk) 20:14, 26 March 2014 (UTC)

side-half-hipped?

Es fehlt beispielsweise das Equivalent zu side-hipped für half-hipped, also ein Giebel half-hipped, andere Seite steiler Giebel.

Ähnlich manche aufwendigeren Dachformen, bei denen ein steiler Giebel nicht ganz in die Dachform paßt.

Basstoelpel (talk) 16:44, 7 February 2015 (UTC)

roof:direction nutzen

Gerade bei nicht einzelstehenden (Einfamilien-)häusern gibt es bei dem aktuellen hier beschriebenen Schema das Problem, dass die Anzahl der verschiedenen roof:shapes explodiert bei aneinander stehenden Gebäuden, und mit ihm auch die Komplexität für Mapper.

Beispiel für das Problem

Ein Endhaus einer Häuserreihe die ansonsten roof:shape=gabled ist.

roof:shape=side_hipped + roof:direction=S (wenn es nach Süden geht)

Scheint erstmal simpel zu sein. Allerdings braucht es so für jede einzelne 2-seitige Dachform wiederum eigene roof:shape Definitionen der 3-seitigen Dachform, also u.A. für flat, skillion, gabled, half-hipped, gambrel, saltbox, round, round_skillion und round_gabled.

Doch dem nicht genug, was ist mit Eckhäusern in einem Häuserblock? Die sehen oft so aus:

In der englischen Version dieses Artikels wurde vorgeschlagen, für gabled dann noch ein value, roof:shape=L_gabled einzuführen. Dasselbe müsste man mit allen anderen Dachvarianten machen.

So, und das ist leider noch immer nicht genug, denn T-Formen (3 Seiten) gibt es ja auch noch.

Insgesamt ist man also bei 9*4 = 36 verschiedenen Definitionen für roof:shape bei eigentlich nur 9 verschiedenen Dachformen (entsprechend mehr pro jede weitere grundlegende Form), sie unterscheiden sich nur dadurch wie viele und in welche Richtung die Dachseiten zeigen.

Das wiederum, gerade weil eben nicht all diese 36 Dachformen in diesem Artikel dokumentiert sind, sorgt dann dafür dass Mapper eigentlich unrichtigerweise z.B. roof=gabled eintragen, weil das Dach "vorwiegend" ein Giebeldach ist, statt die korrekte L-, T- oder Endform zu taggen.

Lösung

Ja moment, war da nicht ein Tag für "Richtung der Dachseiten"? Folgender Vorschlag: roof_direction darf eine kommaseparierte Liste aus Seiten haben. Beispiele:

• roof:shape=gabled + roof:direction=S,E ist dann ein L wie oben zu sehen (wenn rechts Osten ist)
• roof:shape=gabled + roof:direction=W,S,E ist dann Endstück wie oben zu sehen
• roof:shape=gambrel + roof:direction=S,E ist dann ein L wie oben, aber eben in Mansarddachform

Als Vereinfachung für Mapper ist der default wenn weder roof:orientation noch roof:direction angegeben sind und das Gebäude nicht frei steht, dass die Dachseiten überall dort sind, wo kein direkt angrenzendes Gebäude steht. Steht das Gebäude also in einer Reihe, ist der default dass vorne und hinten das Dach ist. Steht es an der Ecke, ist der Default eine L-Form.

Der default ist also so festgelegt, dass in den meisten Fällen der Mapper tatsächlich wie oben im letzten Absatz der Problembeschreibung beschrieben, nur die grundlegende Dachform taggt und damit dann auch fertig ist. Im Falle von roof:shape=skillion ist es also (nicht mehr) Pflicht, die Richtung mit anzugeben wenn das Gebäude nicht frei steht.

Rückwärtskompatibilität

Sehr viele roof:shapes haben sich mit dieser Erweiterung der roof:direction Definition erledigt. Um zu zeigen wie viel simpler und gleichzeitig flexibler das wird, hier eine Tabelle die zeigt, welches Tagging mit welcher aktuell definierten Dachform äquivalent ist (und diese damit eigentlich überflüssig macht):

roof:direction / roof:shape	nur eine (T-Form)	W,E oder N,S (normal)	2 benachbarte (L-Form)	alle außer 1 (Endstück)	(alle)
skillion	skillion	-	double_skillion	triple_skillion	-
gabled	(N/A)	gabled	L_gabled	side_hipped	hipped
half-hipped	(N/A)	half-hipped	(N/A)	(N/A)	-
gambrel	(N/A)	gambrel	(N/A)	mansard_onesided	mansard
saltbox	saltbox	double_saltbox	corner_saltbox	triple_saltbox	quadruple_saltbox
round	(N/A)	round	(N/A)	(N/A)	dome
round_gabled	(N/A)	round_gabled	(N/A)	(N/A)	round_hipped
round_skillion	round_skillion	-	round_skillion_cutted	round_skillion_double_cutted	-

(N/A) für Formen die (noch) keine Namen haben.

Saltbox value

Note that saltbox value is problematic due to conflicting definitions and meanings of "saltbox" in this context. See https://wiki.openstreetmap.org/wiki/Template:Roof:shape https://lists.openstreetmap.org/pipermail/tagging/2020-February/thread.html#51110 for more info. Mateusz Konieczny (talk) 13:00, 6 November 2020 (UTC)