… ja, vermute ich auch, aber ist das in diesem abgeleiteten roof:[x]-Kontext sinnvoll bzw. praxisgerecht (habe Node in meinen direction/orientation als sinnfrei gecancelt)?
Nodes findet man häufig in Verbindung mit Adressdaten. Sobald das Gebäude vollständig gemappt wurde, sollte der mit dem Node verbundene building key mit allen zusätzlichen Angaben gelöscht werden. JOSM wird dann eh von sich aus warnen. Ich erlebe sowas häufig beim Nachzeichnen von öffentlichen Gebäuden.
Habe die Tabelle mal “sortable” gemacht, jetzt kann jede/r um- und unstrukturieren (1)
oder besser ohne Zwischenüberschriften (2)
oder 1:1 in der EN-Reihenfolge - wird sich bestimmt schon wer was bei gedacht haben, oder?-) (3)
Zu den beiden roof:orientation-values (along/across) habe ich (EN) redirects angelegt, um einer weiteren sinnfreien Ausfransung der Wiki-Dokumentation vorzubeugen.
Hallo,
ich hatte mal nen Test gemacht, Ein Gebäude mit skillion und roof:orientation=along
Dann das Gebäude immer wieder gedreht und im Kreis angeordnet.
Hier das Ergebnis in F4map.
Erstens sind die Angaben zu roof:orientation nicht um 180 Grad gedreht: 350 und 167 Grad passt nicht zueinander.
Zweitens dreht roof:angle=347 quasi (vermutlich) einmal um sich selbst und damit verkehrtherum, also statt 10 Grad nach oben nun 13 Grad nach unten. Wenn orientation um 180 gedreht ist, sollte der Winkel (Dachneigung) die gleiche sein. Also beide 10 Grad.
Bei realen Steildächern habe ich (zumindest in D) noch nie etwas von Dachneigungsangaben > 90° gelesen oder gehört.
Die übliche Angabe bezieht sich auf den Innenwinkel zwischen Dach und Geschossebene, realistisch sind dabei Werte zwischen ca. 10 und 70°.
Wobei die Dach-Ausrichung (OSM roof:direction) mit dessen Dachneigung (OSM roof:angle) nix zu tun hat.
Wenn beide Dächer gleich stark geneigt sind, dann wäre die Gradangabe auch gleich. Siehe auch #58 und #59
roof:orientation müsste 77° bzw. 257° sein.
Aber so weit ich weiß unterstützt F4 bei Pultdächern nur roof:direction (ggf. mit roof:height). Ist eindeutig und reicht.
Alles Andere hat nichts mit dem Tagging zu tun, sondern wird aus der Form des Gebäudes “interpretiert”.
347° bzw. 167° wäre hier roof:direction. Wenn man den Winkel weiß, dann kann man auch die Dachhöhe (roof:height) ausrechnen.
Blöderweise wird aber die Höhe vom building abgezogen. Wenn nämlich das building ein :levels hat, aber das Dach keines, dann gilt das :levels als Gebäudegesamthöhe. (Fand ich schon immer blöd.)
versuche roof:direction=* für Gradangabe und die von hoch nach tief.
also beim oberen Gebäude roof:direction=167 und beim unteren Gebäude roof:direction=347
roof:oriantation ist falsch (das war mir bei meiner ersten Antwort noch nicht aufgefallen), bei Pultdächern muss roof:direction verwendet werden.
Der Winkel der Dachneigung ist von First (hoch) nach Traufe (niedrig) anzugeben, 350 sind also auch falsch, es müsste dann also 170 sein.
roof:angle wäre dann 13 und nicht 347
Die Dachneigung ist von außen in die Mitte abfallend also müßten meine Maße schon stimmen
beim oberen Gebäude roof:direction=167 und beim unteren Gebäude roof:direction=347
Ich hatte nichts anderes [geschrieben] gemeint, nur die exakte Gradangabe habe ich nicht überprüft, sondern aus Teilen des ursprünglichen taggings übernommen. Dabei ist mir bei der zweitrn Angabe ein Schreibfehler unterlaufen. Eigentlich wollte ich 170 schreiben.
Mir war bereits aufgefallen, dass roof:angle als einziger Tag aus der roof-Familie,
keine eigene Dokumentationsseite besitzt. Also nicht mal eine schlechte, sondern gar keine.
Je mehr Wikiseiten es gibt, desto höher ist der Pflegeaufwand und das Risiko von Widersprüchen. Daher finde ich es prinzipiell sogar besser, wenn ein Key/Tag, zu dem es nicht viel mehr zu sagen gibt als 2–3 Sätze, keine eigene Seite hat.
Der Auffassung, dass der roof:angle > 0 und < 90 sein muss, würde ich zustimmen.
Die Sache ist aber die, dass Redirects auf Zwischenüberschriften auch Pflegeaufwand benötigen - s.o. der stimmt hinten und vorne nicht (mehr).
und bei der Dachneigungs-Erfassung sehe ich durchaus langfristig Sinnhaftigkeit und Potential.
Aber aufdrängen will ich mich da nicht;-)
“Diese Bauweise ist die häufige Variante, daher nutzen viele Auswerter along als Standardwert.”
Ich finde die Formulierung des Satzes nicht so gelungen.
Besser wäre: Diese Bauweise wird in den meisten Fällen umgesetzt, daher nutzen viele Auswerter along als Standardwert.
Dementsprechend angeglichen: Diese Bauweise wird selten umgesetzt, daher muss across ausdrücklich getaggt werden. [Beispielfoto zeigt einen überdachten Wegweiser.]
Da wären wir wieder beim Wort Variante. Es kann aber auch so bleiben wie es ist. Es ist nur ein Formulierungsvorschlag.
Man sollte einfach nur beschreiben, dass es so gemacht wird und keine Pseudoerklärung dafür liefern.
“Selten umgesetzt” ist auch nur eine gefühlte Wahrnehmung. Im urbanen Kontext ist das bei Reihenhäusern nämlich genau andersherum Sprich: Insbesondere bei einzeln gemappten Reihenhäusern sollte die Dachrichtung erfasst werden.