roof:shape=side_hipped -Richtung angeben

Oder mit einem roof:shape=hipped und einem roof:shape=gabled. Da beißt sich dann nichts.

Das Problem mit roof:direction und roof:shape=side_hipped ist, dass die direction angibt in welche Richtung der Dachfirst abfällt. Da sich daraus für side_hipped gar nichts erschließt, ist der Tag one konkrete Definition, wie man die Richtung angibt, eigentlich nutzlos. Eine Sache habe ich beim 3D-Taggen schnell gelernt: der Renderer macht nicht magisch alles richtig, sondern geht systematisch und teils sehr dumm vor. Wenn etwas uneindeutig ist, dann bekommst Du mindestens 2 verschiedene Ergebnisse.

Wenn in letzter Zeit niemand diese Gegend über F4 angeschaut hat, dann quasi sofort. Ansonsten 3-4 Tage, solange wird scheinbar gecacht. Am besten in der Zwischenzeit mit osm2world arbeiten, das geht ja quasi “in Echtzeit”, wenn man die .osm-Daten aus josm speichert und dann im o2w reloaded.

Eine Sache die ich beim 3D-Taggen gelernt habe ist, dass die ganze Thematik zunehmend in eine kommerzielle Richtung abdriftet. Jeder Anbieter kocht da gern sein eigenes Süppchen. Was ich mir wünschen würde wäre ein structure-Tag welches z.B. auch Brückenkonstruktionen unterstützt. Ob sowas in den nächsten 10 Jahren noch kommt? - schaun mer mal. Aktuell bliebe nur das https://3dmr.eu oder der bestehende Simple-3D-Minimalkonsens. By the way …

roof:shape=hipped, side_hipped, half_hipped, …

ist wegen fehlender Maßangaben leider schon wieder so komplex, dass es nicht allgemein unterstützt wird. Teilweise fehlt dann sogar der Fallback auf roof:shape=gabled. Ähnlich ist die Situation bei round, gambrel, mansard und many. Da muss man dann nach einem anderen Kompromis suchen - was eigentlich nicht vorgesehen ist - oder warten bis sich da nochmal etwas tut. Der Ansatz https://wiki.openstreetmap.org/wiki/OSM-4D/Roof_table geht in diese Richtung, kann aber auch nicht jede beliebige Situation abbilden.

roof:direction …

ist aktuell nur auf einseitig geneigten Dachflächen sinnvoll anwendbar. Bei multiblen Dachflächen kommt stattdessen roof:orientation ins Spiel, welches sich dann auf den Dachfirst und nicht auf die Dachfläche bezieht. Dort gibt es aber bislang keine Winkelangabe, was Giebeldächer mit quadratischem Grundriss zum Glückspiel macht. Ein dummes Versäumnis aus den 3D-Anfangstagen wie ich finde.

… kann man so sehen, man kann sich aber auch auf den Standpunkt stellen,
dass dies 2 unterschiedliche Methoden mit unterschidlichen Datentypen in den values sind, und daher 2 unterschiedliche Keys angebracht sind.

Allerdings hatte ich in der letzten Disk zum Thema schon darauf hingewiesen, dass die Doku lausig ist:
Das “Gesamtsystem” aus roof:direction+orientation wurde überhaupt erst Anfang des Jahres untereinander verlinkt, aber nicht erläuternd abgrenzend in der Einleitung, sondern unter “siehe auch”
https://wiki.openstreetmap.org/w/index.php?title=Key%3Aroof%3Adirection&type=revision&diff=2274177&oldid=1888003

Bei nicht-Pultdächern bestehen logischerweise mind. immer 2 mögliche roof:direction-Werte. Wie soll Mapper damit umgehen? Kein Wort in der vernachlässigten Doku dazu.

JA, dem kann ich nur zustimmen. Die Frage nach der korrekten Anwendung taucht leider immer wieder auf. Die Konfussion darüber hat IMHO historische Gründe. roof:direction kam nach roof:orientation. Vermutlich mit einer angedachten Unterstützung für die Ausrichtung von PV-Anlagen. Wenn dem so ist, sollte dies mal jemand klarstellen.

Da bin ich voll dabei. Meiner Meinung nach ist der Name des Keys “direction” auch ungünstig gewählt. Bei orientation “along” und “across” ist es ja noch eindeutig, dass es um den Dachfirst geht, aber bei “direction” dachte ich ursprünglich auch, dass es um die Ausrichtung des Dachfirstes ging (wenn das Dach denn einen hat) und musste dann erfahren, dass es darum geht in welche Richtung es nach unten geht. Warum? Die Doku ist mehr als mau und ich frage mich ja aufgrund welcher Dokumentation dazu die Implementierungen überhaupt erstellt wurden.

Das 4D-Mapping hingegen ist so abgehoben, dass ich nicht glaube, dass ich die Implementierung eines Karten-Renderers dazu noch erleben werde. Und selbst wenn, fände ich es besser erstmal den 3D-Standard zu fixen und die Bearbeitung dazu in JOSM zu vereinfachen. Wäre z.B. toll, wenn man building:part=* ausgrauen könnte, damit man leichter an die Gebäude kommt, wenn man nicht 3D-Mapping macht, Dachformen als 2D in JOSM darstellen, usw. Da kann man noch Vieles besser machen. Aber auch diese Probleme werden irgendwann gelöst.

Beim 4D-Mapping ist OSM2world am weitesten fortgeschritten. Näheres müsste Tordanik wissen.

… da ja hier weitgehende Einigkeit in der Sache besteht,
habe ich mal die EN-Version von roof:direction
https://wiki.openstreetmap.org/wiki/Key:roof:direction
erstmal in meinem Benutzernamensraum bearbeitend übersetzt:
https://wiki.openstreetmap.org/w/index.php?title=User:Jo_Cassel/Schreibtisch&oldid=2385268
(mit dem Gedanken, diese Klarstellungen auch nach EN zu übernehmen)

mit der Bitte um feedback…

Ich habe direction schon einigemale bei skillion benutzt, aber irgendwie was das Ergebnis immer willkürlich. Die Schräge ist immer gleichmäßig zur längsten Seite, die Abschrägungsrichtung Zufall.
Meist erkenne ich das Prinzip nach einigen Versuchen und Änderungen, da bin ich aber nicht nicht dahinter gekommen, was ich falsch mache.

Ich benutze roof:direction auch nur bei Pultdächern, und schaue mir danach das Renering an. Die Ausweitung auf andere Dachformen führt leider zu mehrdeutigen Interpretationen, und versagt im Fall von pyramidal und dome vollständig.

hallo

die hohe Seite fällt in die Richtung ab die du angibst.
https://wiki.openstreetmap.org/wiki/Key:roof:direction

Ich messe den Winkel mit MB-Ruler am Bildschirm aus

Gruß
Danfost

Kannst Du ein/zwei Beispiele dafür verlinken?
Und den Renderer nennen, der das so macht?

@Jo_Cassel
Bezüglich
https://wiki.openstreetmap.org/wiki/User:Jo_Cassel/Schreibtisch

Die Empfehlung sollte statt
“Der Wert soll als Himmelsrichtung (N, S, NW, ESE), oder als eine angenährte Gradangabe zwischen 0 - 360 erfasst werden.”
besser
Der Wert soll als eine Gradangabe zwischen 0 - 360 oder als angenährte Himmelsrichtung (N, S, NW, ESE…), erfasst werden."
lauten. Schließlich ist die Himmelsrichtung eine Annäherung und nicht der Winkel.

Mmh, doch eher
“Der Wert soll als angenährte Himmelsrichtung (N, S, NW, ESE), oder als eine angenährte Gradangabe zwischen 0 - 360 erfasst werden.”

Ich gehe davon aus, dass der Wert ohnehin noch weiterverarbeitet, bzw. der Winkel mit den Winkeln der Gebäudekanten verglichen werden wuss, vgl.
https://forum.openstreetmap.org/viewtopic.php?pid=870805#p870805

Wenn der Wert direkt genutzt werden soll, dann muss die Dokumentation dem Mapper auch eine wünschenwerte Genauigkeit vorgeben (“möglichst auf +/- 5 Winkelgrad genau”).
Diese Festlegungen sollten aus Auswertersicht getroffen werden…

Wer einmal verstanden hat wie die Winkelmessung in JOSM funktioniert, wird sich kaum mehr mit Schätzwerten abfinden. Daher von mir ein klares PRO für numerische Angaben. Geiches wäre auch bei roof:orientation möglich um die exakte Richtung des Dachfirstes festzulegen. Aber sowas geht nur nach internationaler Abstimmung.

Gedanken nach dem Durchlesen der aktuellen Version:

  • Aus meiner Sicht gibt es keine Präferenz, welcher der beiden möglichen Winkel bei Formen wie gabled gewählt werden sollte. Ich würde den entsprechenden Abschnitt daher ersetzen durch: “Bei einer achsensymmetrischen Dachform (z.B. gabled) ergeben sich zwei mögliche Werte. Davon kann einer beliebig gewählt werden.”

  • Schön wäre, wenn der Bezug in der Einleitung auf die “facing” direction, also quasi “Blickrichtung”, irgendwie erhalten bliebe. Das dient dem Verständnis, warum der Schlüssel so definiert ist, wie er es ist: Der normale Schlüssel direction=* ist ja auch als die “Blickrichtung” eines Objekts wie z.B. einer Parkbank, Infotafel o.ä. definiert.

Ich wüsste nicht, inwiefern der Begriff “Blickrichtung” für alle Dachformen funktionieren könnte. Gerade bei einem Satteldach würde ich persönlich als Blickrichtung nicht die Richtung verstehen, zu der hin das Dach abfällt, sondern die Richtung, in der der Dachfirst verläuft. Aber das ist nur mein ganz persönliches Verständnis, weshalb ich gar nicht erst mit solchen “Eselsbrücken” anfange, sondern mir anschaue, wie es ausgewertet wird.
Editier die Seite am besten mal selbst; ich hab wirklich keine Idee, wie man das sonst formulieren sollte.

Was mir in diesem Zusammenhang noch einfällt: ist definiert, was passiert, wenn roof:direction und roof:orientation beide gegeben sind? Ich würde jetzt zunächst mal davon ausgehen, dass roof:direction spezifischer ist und damit Vorrang hat bei einer Auswertung, aber ich sehe nicht, dass das geklärt ist. Dasselbe problem gibt es ja auch bei roof:height vs. roof:angle. Ist das definiert, oder Sache des Renderers?

Letzteres ist wohl der Fall.

… ist wenig zielführend, über unterschiedliche Versionen zu diskutieren,
bin mal auf die Ursprungsversion zurückgegangen, und habe versucht, dann alles aufgeschnappte auch aufzugreifen:

Aktueller Textvorschlag
https://wiki.openstreetmap.org/w/index.php?title=User:Jo_Cassel/Schreibtisch&oldid=2385899

mit der Bitte um feedback hier

Also mit Begriffen wie “Blickrichtung” kann ich auch wenig anfangen. Gängiger sind da schon solche Begriffe wie traufständig und giebelständig. Bei traufständig würde man eine durchlaufende Traufe sehen.

Die von mir erwähnten Punkte finde ich da gut berücksichtigt, aber ich fand die zwischenzeitlichen Edits von Nadjita eigentlich tendenziell auch sinnvoll. Zum Beispiel dürfte das “gilt diese Erfassung als problematisch” gerne durch ein “ist diese Erfassung nicht geeignet, hier muss roof:direction verwendet werden” (oder eine andere Formulierung mit ähnlicher Aussage) ersetzt werden.

Danke übrigens, dass du dir die ungeliebte Arbeit an der Doku antust. :slight_smile: