Hallo,
ich hab hier
roof:shape=side_hipped
wie gebe ich die Seite an an der die “Hippe” ist.
Mein Gedanke wäre das mit https://wiki.openstreetmap.org/wiki/Key:roof:direction z.B
roof:direction=90
und damit die Seite anzugeben.
Oder macht man das anderst?
Gruß
Danfost
Ps. wie lange kann es dauern bis Änderungen in OSM auf demo.f4map.com gerendert werden?
Muss man das angeben?
Normalerweise ist davon auszugehen, dass die hipped Seite gegenüber der Seite liegt, die sich die Wand mit den Nachbarhaus teilt. Sofern der Renderer das überhaupt auswertet, sollte er das automatisch erkennen können.
side_hipped ist keine der “Kern”-Dachformen von Simple 3D Buildings, daher ist das bisher nicht wirklich definiert.
Naheliegend wäre es, die schräge Seite gegenüber der vertikalen als Richtung zu sehen, weil man ansonsten das Symmetrieproblem hat.
Derart schlau ist meines Wissens bisher kein 3D-Renderer. Und es müsste ja nicht nur ein Renderer so machen, sondern Teil des Standards sein, sonst sieht das überall anders aus. Ich finde diese Regel auch nicht so leicht allgemeingültig zu formulieren, wenn der einstöckige Schuppen an der “anderen” Seite des Gebäudes sie nicht kaputt machen soll.
Da hast Du vollkommen recht. Das verkompliziert die Regel, weil zusätzlich geprüft werden muss ob die beiden Gebäude die gleiche Höhe haben.
so isses! Man könnte das durch ein roof:shape=gabled mit angefügten roof:shape=pyramidal approximieren. Hat dann aber möglicherweise Probleme mit dem Z-Fighting der beiden Gebäudeteile.
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 …
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.
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.