roof:shape=side_hipped -Richtung angeben

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.

Mammi71 wrote:

Normalerweise ist davon auszugehen, dass die hipped Seite gegenüber der Seite liegt, die sich die Wand mit den Nachbarhaus teilt.

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.

Tordanik wrote:

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.

Tordanik wrote:

side_hipped ist keine der "Kern"-Dachformen von Simple 3D Buildings..

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.

googlenaut wrote:

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.

Danfost wrote:

wie lange kann es dauern bis Änderungen in OSM auf demo.f4map.com gerendert werden?

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 ..

1. 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.

1. 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.

googlenaut wrote:

[...]

1. 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. … id=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.

Jo Cassel wrote:

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.

Nadjita wrote:

Da bin ich voll dabei. [...]

... 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. … id=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

wegavision wrote:

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.

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

wegavision wrote:

...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...

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/Use … hreibtisch

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.

pyram wrote:

@Jo_Cassel
Bezüglich
https://wiki.openstreetmap.org/wiki/Use … hreibtisch
[...]

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/viewtop … 05#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.

Jo Cassel wrote:

https://wiki.openstreetmap.org/w/index. … id=2385268

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.

Tordanik wrote:

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?

Nadjita wrote:

Dasselbe problem gibt es ja auch bei roof:height vs. roof:angle. Ist das definiert, oder Sache des Renderers?

Letzteres ist wohl der Fall.

Nadjita wrote:

[...]
Editier die Seite am besten mal selbst; ich hab wirklich keine Idee, wie man das sonst formulieren sollte.
[...]

... 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. … id=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.

Jo Cassel wrote:

Aktueller Textvorschlag
https://wiki.openstreetmap.org/w/index. … id=2385899

mit der Bitte um feedback hier

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. 🙂

@googlenaut
Trauf- bzw. Giebelständigkeit eines Gebäudes bezieht sich immer auf dessen (städte)baulichen Kontext, hilft hier imho nicht wirklich weiter.

@Tordanik
Wenn sich die Interessierten im Kern einig sind, und man die hier jetzt schonmal zusammen hat, ist das Arbeiten an der Dokumentation keine unangenehme Aufgabe.
Hab mein Satzende durch deine Formulierung ersetzt, aktueller Text:

https://wiki.openstreetmap.org/w/index. … id=2386528

gern weiteres feedback hier...

unabhängig vom (städte)baulichen Kontext wäre der Normalenvektor. Dessen Projektion auf die Grundfläche, bzw. dessen Fallrichting, entspräche dann der roof:direction. Damit könnte man sogar entlang der Frontseite abfallenden Dächern eine Richtung geben, sofern dies denn entprechend interpretiert wird. Hat bei einigen meiner Pultdächer jedenfalls so funktioniert.

... in Key:roof:shape findet sich
"Direction from back side of roof to front [...]"
was ich mal lieber nicht als hinten/vorne übersetzen möchte, sondern eher so
"Richtung[svektor] vom Inneren zum Äußeren der Dachfläche(n) [bzw. dessen Projektion auf der Grundfläche]."

habe kein Problem damit, neben/hinter
"Die Ausrichtung der Dachfläche(n) ist definiert in einer gedachten Blick-Richtung von hoch (First) zu niedrig (Traufe), dem Gefälle der Fläche(n)."
noch weitere Gedankenstützen einzubauen sofern gewünscht...

Jo Cassel wrote:

...noch weitere Gedankenstützen einzubauen...

Nicht jeder ist Architekt (First, Trauf- bzw. Giebelständigkeit...) oder Mathematiker (Vektor).
Einfach: Richtung (roof:direction) ist die, in die das Regenwasser abfließt.

... Naja, bei der in Mitteleuropa üblichen Rinnenentwässerung wechselt das Regenwasser an der Traufe seine Richtung radikal;-)

Wie wärs mit dieser Ergänzung:

"Die Ausrichtung der Dachfläche(n) ist definiert in einer gedachten Blick-Richtung von hoch (First) zu niedrig (Traufe), dem Gefälle der Fläche(n). Dies entspricht der Richtung, in der auf Dachfläche(n) Regenwasser abfließt."

Nachtrag/Nachfrage:
In der Info-Box zum Tag läuft der Bezug zu roof:shape=* z.Zt. unter Useful combination - wäre da ein Requires sinnvoll,
oder anders gefragt: ist das Tagging von roof:direction OHNE roof:shape denn überhaupt sinnvoll/üblich (taginfo meldet 98,8%)?

Jo Cassel wrote:

Wie wärs mit dieser Ergänzung:...

Ich finde den Entwurf grundsätzlich schon für gelungen. Bei der Ergänzung würde ich es nicht unnötig verkomplizieren und es bei der Dachfläche bei der Einzahl belassen.

Jo Cassel wrote:

... Naja, bei der in Mitteleuropa üblichen Rinnenentwässerung wechselt das Regenwasser an der Traufe seine Richtung radikal;-)

[Ironie ein]Ja, insbesondere bei den Fallrohren (da brauchen wir unbedingt noch ein Proposal!) sollte man den Vektor unbedingt mit angeben 😛 [Ironie aus]

Jo Cassel wrote:

In der Info-Box zum Tag läuft der Bezug zu roof:shape=* z.Zt. unter Useful combination - wäre da ein Requires sinnvoll,
oder anders gefragt: ist das Tagging von roof:direction OHNE roof:shape denn überhaupt sinnvoll/üblich (taginfo meldet 98,8%)?

Es gibt hier sicherlich immer eine Handvoll Mapper, die auch ein reines "roof:direction" für irgenwelche Zwecke für sinnvoll halten. Muss ja nicht für 3D sein.
Ebenso gibt es genügend Mapper, die anstatt roof=flat roof:levels=0 mappen. Naja: Solange es nicht falsch ist, macht das auch nichts kaputt. Auch häufig ist ein building:levels=* und sonst nichts. Aus 3D-Sicht fehlt da immer eine Aussage zur Dachhöhe/Form.

Zusammengefasst: "requires" ist zu streng. Und die Mehrheit wird es so oder so sinnvollerweise mit roof:shape=* erfassen.

Die Ergänzung in Einzahl...
https://wiki.openstreetmap.org/w/index. … id=2388790

gern weiteres feedback zum aktuellen Text...

pyram wrote:

[...]
Zusammengefasst: "requires" ist zu streng. Und die Mehrheit wird es so oder so sinnvollerweise mit roof:shape=* erfassen.

Kann ich mit leben,
aber da ich auch vorhabe, das "Geschwister" roof:orientation noch etwas zu ergänzen,
wundere ich mich über die unterschiedliche Einordnung in den Info-Vorlagen, konkret
"building=* [or] building:part=*/yes" ist mal Requires und mal Useful combination ??

Jo Cassel wrote:

"building=* [or] building:part=*/yes" ist mal Requires und mal Useful combination ??

Ja das ist natürlich nicht gut. roof:direction und roof:orientation benötigen beide roof:shape und building:part oder building. Sollte man sicher klarstellen, aber auch, dass roof:direction und roof:orientation nicht zusammen genutzt werden sollten. Das hat mich anfangs nämlich auch ein wenig verwirrt.

.. habe jetzt mal
in roof:direction das
Requires building=* or building:part=*
aus roof:orientation übernommen.
Mir kommt es weniger darauf an, welche Links wie eingeordnet werden, aber darauf, dass dies bei den beiden Geschwister-Tags identisch ist.
In diesem Zusammenhang meine Frage zu height=*, müsste da nicht
height=* or roof:height=*
stehen?

Stand der Dinge, nachdem ich angefangen habe, auch den anderen Text entsprechend zu bearbeiten:
roof:direction
https://wiki.openstreetmap.org/w/index. … id=2389095
roof:orientation
https://wiki.openstreetmap.org/w/index. … id=2389099

Nadjita wrote:

[...] aber auch, dass roof:direction und roof:orientation nicht zusammen genutzt werden sollten. Das hat mich anfangs nämlich auch ein wenig verwirrt.

Könnte in beiden Texten einleitend ergänzen:
"Diese beiden Tags sind gegenseitige Alternativen und sollten nicht gemeinsam genutzt werden."
sofern es keine Einwände gibt...?

Jo Cassel wrote:

In diesem Zusammenhang meine Frage zu height=*, müsste da nicht
height=* or roof:height=*
stehen?

Eigentlich ist beides interessant, denn wenn man mit roof:height=* arbeitet, sollte man, muss man aber nicht, auch height=* nutzen. Aber für die Modellierung des Daches selbst ist ja nur roof:height=* interessant. Ich würde also nur "roof:height=* or roof:angle=*" sagen, es geht hier immerhin nur ums Dach.

Jo Cassel wrote:

Könnte in beiden Texten einleitend ergänzen:
"Diese beiden Tags sind gegenseitige Alternativen und sollten nicht gemeinsam genutzt werden."
sofern es keine Einwände gibt...?

Das finde ich eindeutig. Dafür!

Nadjita wrote:

[...]Aber für die Modellierung des Daches selbst ist ja nur roof:height=* interessant. Ich würde also nur "roof:height=* or roof:angle=*" sagen, es geht hier immerhin nur ums Dach.
[...]

liest sich für mich logisch,
habe das mal so, zusammen mit der Alternativen-Klarstellung, in roof:direction übernommen
(perspektivisch, wenn keine Einwände kommen, soll das so auch 1:1 in roof:orientation):

https://wiki.openstreetmap.org/w/index. … id=2389140

Jo Cassel wrote:

habe das mal so, zusammen mit der Alternativen-Klarstellung, in roof:direction übernommen
(perspektivisch, wenn keine Einwände kommen, soll das so auch 1:1 in roof:orientation):

https://wiki.openstreetmap.org/w/index. … id=2389140

Für mich liest sich diese Seite sehr gut und nachvollziehbar. Auf jeden Fall konsistenter als die alte Version. Topp!

... freut mich

Wenn noch weitere roof:[x]=*-Erwähnung aus Praxissicht sinnvoll ist, in der Vorlagen-Box wäre noch Platz...

Kennt/hat jemand ein *passendes und eindeutiges und gemeinfreies* Bild für roof:orientation=across
also Giebelwand breiter als Traufwand, von der Darstellung sowas in der Richtung
https://commons.wikimedia.org/wiki/File … Malbay.jpg

(Bin auch gern bereit *lizenzrechtlich unbedenkliche* 3D-Renderings aus OSM-Daten (zusätzlich) ins Wiki einzubauen.)

Jo Cassel wrote:

"Diese beiden Tags sind gegenseitige Alternativen und sollten nicht gemeinsam genutzt werden."
sofern es keine Einwände gibt...?

Einspruch. Diese Einschränkung ist völlig unnötig. Es gibt sicherlich Renderer, die nur eine der beiden Varianten nutzen, oder eine der beiden bevorzugen.

Besser: "Diese beiden Tags sind Alternativen. Es ist ausreichend, eine von beiden zu nutzen."

Nadjita wrote:

Ich würde also nur "roof:height=* or roof:angle=*" sagen, es geht hier immerhin nur ums Dach.

Hier gilt analog das Selbe, wie vorstehend (#39).

pyram wrote:

Jo Cassel wrote:

"Diese beiden Tags sind gegenseitige Alternativen und sollten nicht gemeinsam genutzt werden."
sofern es keine Einwände gibt...?

Einspruch. Diese Einschränkung ist völlig unnötig. Es gibt sicherlich Renderer, die nur eine der beiden Varianten nutzen, oder eine der beiden bevorzugen.

Besser: "Diese beiden Tags sind Alternativen. Es ist ausreichend, eine von beiden zu nutzen."

Dem kann ich nur zustimmen. Das Wort Alternative ist selbsterklärend, da muss man nicht schreiben, dass es gegegenseitige Alternativen sind. Man kann sich zwischen zwei Alternativen entscheiden. Hat man sich entschieden, fällt die andere weg bzw. kommt nicht mehr in Frage.

Ich nutze meistens die Variante, die am besten zutrifft.

@Jo Cassel: Warum einfach, wenn es auch kompliziert geht. Man sollte nicht aus allem eine Wissenschaft machen.

Hallo,
mal getestet, auch bei roof:shape=skillion funktioniert along und across--> bloß mit der Richtung haperts 🙂
also doch nix.
https://www.openstreetmap.org/edit#map= … 7/10.96336
https://demo.f4map.com/#lat=48.2961092& … phi=-14.61

Gruß
Danfost

@pyram + Will-Bauna
Hab ich dann mal abgeschwächt, und das "or" zwischen roof:height und roof:angle entfernt - muss mich ja mit Doppeltagging nicht rumschlagen
(4750 = 7.17% aller roof:direction zusätzlich mit roof:orientation - na hoffentlich mit identischer Richtungs-Aussage)
aktueller Text:
https://wiki.openstreetmap.org/w/index. … id=2389540

Gibt es noch weitere roof:[x]=*-Erwähnung die sinnvoll sein könnten?

@Danfost
Naja, es reduziert die Rateoptionen für den Renderer von 4 auf 2 - ist ja schonmal ein Fortschritt;-)
im geplanten Text zu roof:orientation wird schon einleitend auf roof:direction verwiesen:
https://wiki.openstreetmap.org/w/index. … id=2389353

wichtig ist, dass sich orientation auf den Dachfirst und direction auf die Dachfläche bezieht. Das ist jetzt für alle ein wenig klarer. Bei komplexen Grundrissen mit mehr als 4 Eckpunkten (L-shaped, T-shaped, Z-shaped, ... ) wird es dann schwierig mit den Angaben. Hier müssten uns die OSM2world-Coder mal einen Hinweis (Regelsatz o.ä.) geben, wie sie das denn auswerten.

EDIT:
bislang noch nicht im Tagging vorhanden, jedoch für die Berechnung von Dachflächen von Bedeutung und daher in vielen diesbezüglichen Apps zu finden:

• roof:rise= roof:height= Dachhöhe.
  
• roof:span= roof:width= Dachbodenbreite mit roof:run=span/2.
  
• roof:length = Dachbodenlänge.
  
• roof:pitch= Dachneigung als Quotient x/12", Faktor oder Winkel.
  
• roof:overhang= Abstand zwischen Hauswand und Traufe.
  

- span und length lassen sich aus den Geometriedaten berechnen.
- pitch oder slope wären eine gebräuchlichere Alternative zu roof:angle.
- overhang dürfte in der Regel kaum ins Gewicht fallen.
- und dann gäbe es bei roof:edge noch eine Unterscheidung zwischen hip und valley.

aber dies nur der Vollständigkeit halber. 🙂

Jo Cassel wrote:

@pyram + Will-Bauna
Hab ich dann mal abgeschwächt, und das "or" zwischen roof:height und roof:angle entfernt - muss mich ja mit Doppeltagging nicht rumschlagen
(4750 = 7.17% aller roof:direction zusätzlich mit roof:orientation - na hoffentlich mit identischer Richtungs-Aussage)
aktueller Text:
https://wiki.openstreetmap.org/w/index. … id=2389540

Gibt es noch weitere roof:[x]=*-Erwähnung die sinnvoll sein könnten?

@Danfost
Naja, es reduziert die Rateoptionen für den Renderer von 4 auf 2 - ist ja schonmal ein Fortschritt;-)
im geplanten Text zu roof:orientation wird schon einleitend auf roof:direction verwiesen:
https://wiki.openstreetmap.org/w/index. … id=2389353

Geht doch! 🙂

googlenaut wrote:

[...]Bei komplexen Grundrissen mit mehr als 4 Eckpunkten (L-shaped, T-shaped, Z-shaped, ... ) wird es dann schwierig mit den Angaben. Hier müssten uns die OSM2world-Coder mal einen Hinweis (Regelsatz o.ä.) geben, wie sie das denn auswerten.
[...]

... naheliegend wäre, dass das Tagging als für die größte Teilfläche gültig angenommrn wird.

Bei roof:[x] geht es mir nicht um neue Tags zu, sondern darum welche etablierten in Useful combination erwähnt werden sollen.
Als etabliert würde ich mal die in der roof:shape Liste betrachten:
https://wiki.openstreetmap.org/wiki/Key … _roof_tags
Wobei von 7 in der Liste seltsamerweise nur 2 in der Box als Useful combination von roof:shape auftauchen, in der DE-Version sieht dies dann nochmal anders aus?

Theoretisch könnte man wohl alle Dachformen aus einem Netz von skillions aufbauen. Aber mappen möchte sowas natürlich keiner. Das andere Extrem wäre, einen nie ganz vollständigen Katalog von unterschiedlichen Dachformen zuzüglich kryptischer Parameterangaben zu verwenden. Will auch keiner. Roof-Line-Tagging? clever, aber auch nicht das Gelbe-vom-Ei. Da bleiben dann nur die ganz einfachen Formen übrig. Aber selbst damit gibt's Probleme. Man braucht dann wohl so ne Art KI um weiter zu kommen.

googlenaut wrote:

Theoretisch könnte man wohl alle Dachformen aus einem Netz von skillions aufbauen. Aber mappen möchte sowas natürlich keiner. [...]

Nicht nur theoretisch, das Pfettendach, als die übliche Steildach-Konstruktion, kann bautechnisch als eine Kombination von 2 angrenzenden Pultdächern verstanden werden - das aber nur am Rande, für OSM ist das imho keine gute Lösung;-)

Denke mal dass wir mit dem Text(en) soweit durch sind, Stand der Dinge
roof:direction
https://wiki.openstreetmap.org/w/index. … id=2390955
roof:orientation
https://wiki.openstreetmap.org/w/index. … id=2390989
lasse das noch ein paar Tage so liegen, dann EN-Übersetzung und 4x Übernahme ins wiki.

Da im roof-Geschehen Key:roof:shape eine zentrale rolle einnimmt will ich vorab die dortige Tabelle aus EN nach DE übernehmen (z.Zt. läuft das in DE unter siehe auch).
Statt einer 1:1 Übersetzung habe ich die Tabelle mal lieber neu strukturiert, s:
https://wiki.openstreetmap.org/w/index. … id=2390989

Ist das ok so, und können diese 7 Tags als ''Useful combination'' in die EN+DE Info-Box?
Achso, und warum ist eigentlich Node dort als Erfassungsmöglichkeit zulässig?

Jo Cassel wrote:

Achso, und warum ist eigentlich Node dort als Erfassungsmöglichkeit zulässig?

vermutlich weil auch die Erfassung eines Gebäudes als node zulässig ist.

... 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)?

Jo Cassel wrote:

Statt einer 1:1 Übersetzung habe ich die Tabelle mal lieber neu strukturiert

unstrukturiert ist die Tabelle aber leserlicher.

Jo Cassel wrote:

warum ist eigentlich Node dort als Erfassungsmöglichkeit zulässig?

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.

googlenaut wrote:

Jo Cassel wrote:

Statt einer 1:1 Übersetzung habe ich die Tabelle mal lieber neu strukturiert

unstrukturiert ist die Tabelle aber leserlicher.
[...]

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)

https://wiki.openstreetmap.org/w/index. … id=2392143

von mir aus kann es bei (3) bleiben. Da jeder Key einzelnd erklärt wird, sind die Zwischenüberschriften verzichtbar.

Hallo

googlenaut wrote:

von mir aus kann es bei (3) bleiben. Da jeder Key einzelnd erklärt wird, sind die Zwischenüberschriften verzichtbar.

+1

Gruß
Danfost

... wenn mit der EN-Tabelle alle zufrieden sind, lasse ich mal gänzlich die Finger von.

Jetzt im Dokumentations-Namensraum des OSM-Wiki:

EN - als Rückübersetzung der diskutierten DE-Text(e)
roof:direction
https://wiki.openstreetmap.org/w/index. … id=2394868
roof:orientation
https://wiki.openstreetmap.org/w/index. … id=2394874

DE
roof:direction (Neu erstellt)
https://wiki.openstreetmap.org/w/index. … id=2394878
roof:orientation
https://wiki.openstreetmap.org/w/index. … id=2394877

Zu den beiden roof:orientation-values (along/across) habe ich (EN) redirects angelegt, um einer weiteren sinnfreien Ausfransung der Wiki-Dokumentation vorzubeugen.

Grüße in die Runde
Jo

pyram wrote:

wegavision wrote:

...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...

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

https://demo.f4map.com/#lat=49.2206303& … hi=-86.517
Diese Schule hat zwei Pultdächer die beide nach innen nach unten gehen, so wie rechts. Die sind genau 180° verschieden, kann man also kaum was falsch machen, trotzdem klappt das nicht.

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.

In OSM habe ich schon wieder gelöscht.

Gruß
Danfost

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.

Mammi71 wrote:

[...]
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.

wegavision wrote:

https://demo.f4map.com/#lat=49.2206303& … hi=-86.517
Diese Schule hat zwei Pultdächer die beide nach innen nach unten gehen, so wie rechts. Die sind genau 180° verschieden, kann man also kaum was falsch machen, trotzdem klappt das nicht.

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.)

Hallo

wegavision wrote:

https://demo.f4map.com/#lat=49.2206303& … hi=-86.517
Diese Schule hat zwei Pultdächer die beide nach innen nach unten gehen, so wie rechts. Die sind genau 180° verschieden, kann man also kaum was falsch machen, trotzdem klappt das nicht.

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

Gruß
Danfost

der nördliche Teil ist aktuell so gemappt

building:colour=yellow
building:levels=1
building:part=yes
roof:angle=347
roof:colour=white
roof:orientation=350
roof:shape=skillion

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

der südliche Teil:

building:colour=yellow
building:levels=1
building:part=yes
roof:angle=10
roof:colour=white
roof:orientation=167
roof:shape=skillion

dass die Dachneigung richtig gerendert wird ist wohl eher Zufall. auch hier roof:direction=350

Hallo

Mammi71 wrote:

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

wegavision wrote:

Diese Schule hat zwei Pultdächer die beide nach innen nach unten gehen,

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

Danfost wrote:

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.

Stattdessen gibt es diesen verunglückten Redirect
https://wiki.openstreetmap.org/w/index. … edirect=no
der aus dem Key-Namensraum in den Allgemeinen führt, sowas halte ich prinzipiell für eine ganz schlechte Idee.

Wenn Einigkeit besteht, dass ein sinnvoller value für die Dachneigung immer > 0 und < 90 sein muss, vgl. #59,
wäre ich bereit was zu schreiben, EN+DE.

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.

Tordanik wrote:

Je mehr Wikiseiten es gibt, desto höher ist der Pflegeaufwand und das Risiko von Widersprüchen. [...]

Das sehe ich grundsätzlich auch so, und hatte daher in diesem Sinne kürzlich diese Redirects angelegt
https://wiki.openstreetmap.org/w/index. … edirect=no
https://wiki.openstreetmap.org/w/index. … edirect=no

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;-)

Jo Cassel wrote:

Tordanik wrote:

Je mehr Wikiseiten es gibt, desto höher ist der Pflegeaufwand und das Risiko von Widersprüchen. [...]

Das sehe ich grundsätzlich auch so, und hatte daher in diesem Sinne kürzlich diese Redirects angelegt
https://wiki.openstreetmap.org/w/index. … edirect=no
https://wiki.openstreetmap.org/w/index. … edirect=no

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.

Gruß Will-Bauna

Will-Bauna wrote:

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.]

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 :-P Sprich: Insbesondere bei einzeln gemappten Reihenhäusern sollte die Dachrichtung erfasst werden.

pyram wrote:

Im urbanen Kontext ist das bei Reihenhäusern nämlich genau andersherum

Absolut korrekt. Ich würde mich auch nie auf den "Standard" verlassen, sondern immer explizit along oder across taggen und das auch im Wiki empfehlen:

»Es wird empfohlen, roof:orientation=* immer explizit zu setzen und sich nicht darauf zu verlassen, dass ein Standardwert genutzt wird.«

Bei simplen Grundrissen funktioniert das. Bei strukturierten Gebäudelängstseiten wäre ich mir da nicht so sicher. In diesen Fällen würde ich der roof:direction den Vorzug geben.

pyram wrote:

[...]Im urbanen Kontext ist das bei Reihenhäusern nämlich genau andersherum :-P Sprich: Insbesondere bei einzeln gemappten Reihenhäusern sollte die Dachrichtung erfasst werden.

Naja, es ist halt so, dass (versetzte Satteldach) Reihenhäuser der einzige Typus sind, bei dem eine Firstrichtung parallel zur kürzeren Gebäudekante (Eingangsfront) überhaupt eine nenneswerte Rolle in der (mitteleuropäischen) Architektur spielt [ein derartiger Beispielbild (Reihenendhaus mit Teil-Giebelansicht) ist sehr wünschenswert].
Die überwiegende Ausrichtung an der längeren Seite ist keine komische OSM-Idee, sondern beruht auf Konstruktionsprinzipien im Holzbau und der Raumausnutzung.
Dies war im vorgefundenen Text auch schon angelegt (vgl. Versionsgeschichte). Ich hatte nur "detached buildings" weiter gefasst, weil dies auch im Zeilenbau und bei geschlossener Blockrandbebauung der Fall ist.

Seit meiner Ankündigung 2022-09-09
https://forum.openstreetmap.org/viewtop … 11#p871511
hatte ich am Text übrigens nichts mehr geändert.

@Nadjita Das Setzen von "along" (sofern nicht roof:direction) ist jedenfalls sinnvoll, schon allein um nachfolgenden Mappern anzuzeigen, dass sich bereits jemand mit dem Thema beschäftigt hat.

An der Dachneigungs-Dokumentation ( https://wiki.openstreetmap.org/wiki/Key:roof:angle ) scheint mir kein Interesse zu bestehen ...?

Bevor hier die Lichter ausgehen, habe ich mal für roof:orientation=across
ein passendes Photo gemacht, und den Text hinsichtlich Reihenhäuser ergänzt:

DE
https://wiki.openstreetmap.org/w/index. … id=2394877
EN
https://wiki.openstreetmap.org/w/index. … id=2394874

Grüße
Jo

Hallo

Jo Cassel wrote:

... habe ich mal für roof:orientation=across ein passendes Photo gemacht, und den Text hinsichtlich Reihenhäuser ergänzt:

+1

Gruß
Danfost