roof:shape=side_hipped -Richtung angeben

… 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.php?title=User:Jo_Cassel/Schreibtisch&oldid=2389095
roof:orientation
https://wiki.openstreetmap.org/w/index.php?title=User:Jo_Cassel/Schreibtisch2&oldid=2389099

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…?

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.

Das finde ich eindeutig. Dafür!

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.php?title=User:Jo_Cassel/Schreibtisch&oldid=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:Old_shed_with_dry_stone_masonry_in_Cloonbony_Milltown_Malbay.jpg
?
(Bin auch gern bereit lizenzrechtlich unbedenkliche 3D-Renderings aus OSM-Daten (zusätzlich) ins Wiki einzubauen.)

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

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

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 :slight_smile:
also doch nix.
https://www.openstreetmap.org/edit#map=20/48.29597/10.96336
https://demo.f4map.com/#lat=48.2961092&lon=10.9632643&zoom=21&camera.theta=72.552&camera.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.php?title=User:Jo_Cassel/Schreibtisch&oldid=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.php?title=User:Jo_Cassel/Schreibtisch2&oldid=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. :slight_smile:

Geht doch! :slight_smile:

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

Bei roof: 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:shape#Other_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.

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.php?title=User:Jo_Cassel/Schreibtisch&oldid=2390955
roof:orientation
https://wiki.openstreetmap.org/w/index.php?title=User:Jo_Cassel/Schreibtisch2&direction=prev&oldid=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.php?title=User:Jo_Cassel/Schreibtisch2&direction=next&oldid=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?

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

unstrukturiert ist die Tabelle aber leserlicher.

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)

https://wiki.openstreetmap.org/w/index.php?title=User:Jo_Cassel/Schreibtisch2&oldid=2392143

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