Warum?
Es gibt massenweise Gebäude wie dieses: http://www.openstreetmap.org/way/31363495
Entweder bemüht man sich mit dem Zeichnen der Dachlinien, was ziemlich viel Zeit kostet und ungenau ist, oder, wie ich in vielen Städten beobachte, man lässt diese Gebäude aus.
Ich glaube, es wäre eine Bereicherung, wenn wir diese Form in S3DB aufnehmen würden.
Richtig! Genau so.
Und die frage nach der Ausrichtung ist berechtigt:
Ich baute soeben noch die Richtungen wie NO ein!
Somit muss es eigentlich selbsterklärend sein.
Der rendering- Algorithmus sollte eine gewisse Unschärfe bei den Winkel haben, damit man richtige Ergebnisse bekommt: also z.b NO auch richtig interpretieren wenn die Ausrichtung nicht exakt 45 Grad ist.
Die Richtungsangabe könnte mit meinem Vorschlag analog zu hipped erfolgen: Die Blickrichtung einer der größeren Dachflächen wird über roof:direction angegeben. Den Parameter “l2” gibt es dann mit den Suffixen :left und :right, die relativ zur roof:direction sind.
Scheint mir zu kompliziert. So wie in #1 beschrieben ist das intuitiver.
Das Problem ist für den Mapper die Berechnung von dem Wert für den Parameter l2. Meistens haben wir mit Winkelhalbierenden zu tun und der Parameter ist überflüssig.
Wir können ja eine Umfrage starten.
Und wie mappen wir Dächer, bei denen diese Schräge zwar steil, aber nicht senkrecht ist? Mit deiner Lösung können wir die beiden Extremfälle mappen, alles dazwischen aber nicht.
Klar ist er meist überflüssig, er soll ja auch optional sein. Bei dem hier diskutierten Fall braucht man auch nix berechnen, da ist der Abstand 0.
Ja, das ist universeller. Oft kämpfe ich mit dem Problem, dass die Dachschrägen auf den kurzen Seiten eine andere Neigung haben, als F4 und Kendzi das sehen…
Das ist eine praktikable Lösung. Ob es allerdings mit KISS funktioniert?
Wünschenswert ist es schon und es scheint vordergründig einfacher zu sein als Tordaniks Lösung. Wenn man sich aber mit dem Tagging, auf welcher Seite nun die Brandwand ist, beschäftigt, dann ist es auch nicht einfacher.
Der Vorteil von Tordaniks Lösung ist auch, dass Renderer weniger Dachformen beherrschen müssen und für schnelle grobe Dachlandschaften einfach die ganzen Details weglassen können, ohne dass es wesentliche Fehler ergibt.
Einfach die genau Gradzahl, damit der Renderer nicht raten muss
Na ja, wir haben mit Hinblick auf die Einfachheit des Mappens viele Formen die eher selten auftreten ausgelassen.
Denkt man Deinen Ansatz zu Ende, dann würden wir mit nur roof:shape=hipped auskommen, da wir mit beidseitig l2=0 daraus auch die Form “Gabled” haben könnten.
Natürlich ist dieser Ansat flexibel, sonst hätte ich ihn in meiner Dachtabelle nicht vorgeschlagen.
Prozentuell gesehen sind solche Dachformen jedoch deutlich seltener.
ich finde das Prinzip https://wiki.openstreetmap.org/wiki/DE:OSM-4D/Roof_table gut, aber es stellen sich mir noch so ein paar Fragen:
In der Translationstabelle taucht kein “side_hipped” auf… gibt es nun diesen Wert oder kann er durch “hipped” und L2 und L3 ausgedrückt werden? Außerdem fehlt in der “Dächer mit zwei Ebenen”-Tabelle der L3-Parameter in der Zeichnung bei “hipped”. Das wird so nicht ganz klar. Auch sollte in den Zeichnungen immer der Richtungspfeil eingezeichnet sein, dieser ist bei 1.0 und 1.1 vorhanden, bei 2.2 herrscht aber Verwirrung bzw. dort ist es kein Richtungpfeil, sondern zeigt eher auf S.
Außerdem überzeugt mich das Beispiel in “Ausichtung des Umrisses” nicht so ganz. Vielleicht kann man da noch die Richtung einzeichnen… Brauchen wir P (3dr:direction=end) überhaupt, wenn der Gebäudeumriss sowieso immer eine Richtung hat? Dann wäre P einfach der vorherige Punkt vor S (bzw. der letzte der einen Winkel aufweist, da ja auch redundante Punkte vorkommen können)? Oder ist die Richtung kein fester Indikator? Anders: Ist der Vektor PS gleichbedeutend mit “roof:direction” oder “roof:orientation”?
Außerdem verwirrt mich der Wert “half-hipped”. Dieser ist in S3DB mit “-” geschrieben. In OSM-4D aber mit “". Nach Konvention der anderen Werte müsste es “half_hipped” heißen. Natürlich wird die “-” viel häufiger verwendet, aber im Wiki sollte schon einheitlich “-” oder "” verwendet werden…Die Wiki-Seite ist schließlich eine Richtlinie für alle. Deshalb wäre ich für die Umbenennung in “half_hipped”, dann würde auch mehrheitlich dieser Tag verwendet werden. Entgegen des Talks(https://wiki.openstreetmap.org/wiki/DE_talk:OSM-4D/Roof_table). Salopp: Nur weil es mehr machen, ist es ja nicht richtig(er).
Danke, ich hoffe die Punkte sind rübergekommen, und danke allen die bereits zum Wiki beigetragen haben.
Grüße,
Rebo
Der Unterstrich steht in Schlüsseln und Werten für ein Leerzeichen. Das englische Wort “half-hipped” wird aber nicht mit Leerzeichen, sondern mit Bindestrich geschrieben, siehe z.B. auf dict.cc. Von daher liegt die Mehrheit mit roof:shape=half-hipped in diesem Fall durchaus richtig.
Genau solche (eindeutige) Probleme sollten in der Datenbank behoben werden. Ähnliche Schlüssel oder Werte sollten korrigiert werden, damit für Auswertungen Einigkeit besteht.
Zur Zeit ist es doch so:
Schaue ich nach, weil ich einen Schlüssel/Wert suche, habe ich mehrere Auswahlmöglichkeiten. Ich hatte das auch schon bei lastcheck, last_checked, last_check, Check, … und ähnlichen angesprochen.
Wir wollen hier: http://sotm-pl.eu/en/ über die Erweiterung von dem S3DB reden.
Ihr seid herzlich willkommen.
Ich bin sehr selten bei Konferenzen, ich möchte aber die Gelegenheit nutzen um dieses Thema in der Gruppe zu diskutieren.
Mir fällt dazu auch etwas ein: Wisst ihr mit welchem roof:shape man so ein klassisches Bahnsteigdach beschreibt, das ist ja häufig, wie soll man sagen, so eine Art umgedrehtes Satteldach? Also so ein Dach mit zwei Hälften, beide schräg/geneigt und der First, also die Mitte des Daches, liegt tiefer und eben nicht höher als die Ränder des Daches. Kennt ihr bestimmt…
Ich hatte daran gedacht, dass man vielleicht zwei building:part mit roof:shape=skillion macht, aber ob das das Richtige ist, weiß ich nicht.
Bin auch dieser Meinung, Mech. Edit o.Ä. stellt aber hohe Anforderungen oder ist nicht so gern gesehen. Fragt sich ob der Kosten-Nutzen-Aufwand bei eindeutigen Schreibfehlern das wert ist, alles einzeln abzuklappern.
Das ist ja noch relativ lang hin. Zumindest ich als “Neueinsteiger” werde dort wohl nicht hinfahren.
Kann man die oben genannten Aspekte zumindest schon teilweise ins OSM-4D Wiki einfließen lassen? Finden diese überhaupt Zustimmung ??
Wäre sinnvoll oder man benutzt “water drop” und setzt height == D1 und H1 == (1/2)*height. Wenn ich das richtig verstehe, dass H1 für den Mittelpunkt des Ellipsoid steht; ist im Wiki auch noch nicht eingezeichnet. Dann spart man sich einen zusätzlichen shape, der sowieso nur selten auftritt.
Könnte man wohl auch mit roof:shape=saltbox bewerkstelligen: H1 == H2 > height
Ob das den Sinn von Saltbox widerspiegelt sei mal dahingestellt. Das müsste ein Erfahrener beurteilen ;D
- das ist sinnvoll! Dann müsste es aber ergänzend wohl auch “half-round” und womöglich “side-hipped” und “double-gabled” heißen?
??