… 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?
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.
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):
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.
@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?
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.
… 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;-)
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?
… 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)