wenn ALLE Wände Start- und Endnoden mit dem Tag building: colour:= haben, spielt die Richtung keine Rolle → JA
Multipoligon building=, mit mehreren Linien mit building:colour= ist natürlich zulässig. Ich denke nur, es ist mehr Aufwand für den gleichen Ziel.
Was ich bei der Lösung nicht verstehe, ist, daß zum Beschreiben der Eigenschaft von Teilstücken einer Linie die beiden Endpunkte getaggt werden.
Das ist in etwa so, als ob wir eine lange Residential erfassen und an die Nodes die unterschiedlichen Namen der Strassenteile von-bis dranschreiben würden. Bei Highways hat auch keiner ein Problem damit, wenn die an den notwendigen Stellen aufgebrochen werden.
Irgendwie sehr merkwürdig “von hinten durch die Brust ins Auge” - Hauptsache kein MP, dafür tun wir alles. 
Gruss
walter
Wir müssen schlichtweg ein building=yes Umriß nicht in mehrere Linien zerlegen. Die Datenmenge ist dadurch kleiner.
Wir taggen nur die Zwischenpunkte einer Polylinie statt der Endstücke mehrerer Teillinien.
Sorry, kein Mapper kontrolliert die Flussrichtung des building-tags. Viel zu große Unsicherheit.
Wenn man nun die Wand, die eine andere Farbe hat, so taggt: ( Linker Gebäudepunkt / Rechter Gebäudepunkt )
building:colour:right=XXXX
building:colour:left=XXXX
hat man doch eine genaue Definition. Und wenn dort ein Wert fehlt oder nicht übereinstimmt, wird der tag ignoriert. Eigentlich ganz einfach.
+1
Wenn ist richtig das Wiki verstehe http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings
kommt es bei roof:shape=skillion auch auf den ersten Node des Gebäudepolygons an… Das sollte auch anders gelöst werden.
Unabhängig davon wäre ich auch froh, wenn es in JOSM die optionale Möglichkeit gäbe, den Startnode optisch anders darzustellen als die restlichen…
Sven
Stimmt. Deswegen braucht man ein Editor dafür.
Ich plane ein JOSM plugIn mit 3D preview, sowie Einbau von 3D in iD Editor.
Ich kann mir gut vorstellen, daß mit OGC-konformen Datentypen einiges einfacher wäre… da da neben x-y- Werte auch Z-Werte zugelassen wären…
Man bräuchte dann nicht an diverseste Tag-Kombinationen herumdoktern… wo dann kaum einer nocxh durchsieht…
Sven
Hallo Sven,
könntest Du diesen Gedanken ein Wenig genauer beschreiben?
Dass die z-Werte in Zukunft gut wären, ist ja klar.
Viele Grüße,
Marek
letztes Argument, wenn einem garnix mehr einfällt. Gilt für Straßen genauso - und die trennen wir natürlich auf.
ok, war mir leicht missverständlich formuliert - aber ist genau so wenig sinnbehaftet. Ihr “zerlegt” Linestrings in “virtuelle” Teilstücke (von-bis) . Eine Konstruktion, um die euch jeder Mapper beneidet.
Ok, einen Vorteil hat das Konstrukt: Wer es einfach ignoriert, merkt nix davon. Daher ignoriere ich das jetzt hier auch.
Gruss
walter
+1
Bin der Meinung, eine zweite Linie aufzusetzen auf das Gebäude oder sonstige Hilfslinien, ist absoluter Quatsch. Taggen für den Renderer. Ebenso Polygone.
Und sich um die Flussrichtung einer Gebäudelinie zu kümmern, nochmals ebenso. Rechts <> Links mit Bestätigung reicht hier! Da kann man alle 4… Wände mit allen Farben garnieren. Ich erwarte ein Proposal. (Endlich mal eins im 3D Bereich).
Anh. In etwa so ( Eckpunkte des Hauses anklicken): https://www.openstreetmap.org/way/53161687
Hi Rogehm,
passt. Allerdings dieser Punkt wäre überflüssig:
https://www.openstreetmap.org/node/672773499
Die Farbe gilt solange nach links oder rechts bis ein anderer Punkt kommt, der neue Farbe angibt.
& Walter: Ich verstehe Deine Einwände nicht.
Die Datenmenge bleibt kleiner wenn wir die Farben über Attributte der Punkte definieren. Sonst müssen wir neue Linien zeichen.
Klar: Wir zerlegen die Straßen, weil wir da keine andere Alternative haben.
Start- und Endpunkt zu taggen, ist äußerst ungünstig. Was ist wenn sich mehrere Start- und Endpunkte kreuzen? Oder wenn sich beim Farbvalue verschrieben wird?
Das ganze ist wenig intuitiv.
Eine Linie auf den Gebäudeumriss zu setzen ist deutlich einleuchtender. Mit min und maxheight kann man sogar (rechteckige) Flächen bilden.
Ob diese Linie auf einen geschlossenen way aufgesetzt wird, oder der way gesplittet, als Multipolygon ja oder nein, darüber kann man sich streiten.
Stimmt. Ein guter Gegenargument! Man müsste zusätzliche Punkte einführen die neben dem eigentlichen Punkt liegen, wo sich zwei Gebäudegrundrisse begegnen ( z.B. wie hier:Node: 1820826559 | OpenStreetMap).
Und das ist nicht elegant. Für allein stehende Gebäude geht das aber.
Ja stimmt. Hab nur mal schnell ein Beispiel erstellt, was ich heute Abend wieder lösche. Aber hier braucht man kein plugin für JOSM oder ID oder Potlatch. Ein sehr einfaches Tagging.
Ich wäre froh, wenn man sowas etablieren könnte.
Wir bauen dies im ersten Schritt in das JOSM PlugIn ein.
Viele Grüße,
Marek
Hey, nicht so schnell. Das war nur ein Vorschlag. Komplett undokumentiert. Ich mache gerne ein Wiki-Beschreibung, aber lassen wir die Diskussion doch noch was laufen, oder?
Anh. Was ist, wenn das Haus schon eine Grundfarbe hat? Wer/was wird favorisiert?
Na klar.
@Marek: Dann könnten wir dein Konzept mit den Horizontalfarben gleich mit einbauen.
z.B.
building:colour:left:horizontal:1=#FARBE|HÖHE ....
Möglicherweise gar dazu eine Vertikalvariante, bis wohin der Farbverlauf geht ( bin noch am grübeln - möglicherweise mit einem Zwischenpunkt auf der Gebäudelinie )
Hätte was. Wobei ich nicht weiß, wie man am schlausten eine Kombination von horizontalen und vertikalen Werten macht.
Der Nachteil meines Vorschlages ist: Man braucht mindestens zwei identische tags am Gebäude, aber einmal mit “right” und einmal mit “left”.
Das ist aber gleichzeitig auch ein Vorteil: Man kann theoretisch 100 Farben und Farbverläufe über die Gebäudelinie verteilen, bei entsprechender Anzahl an Zwischenpunkten.
Vielleicht wäre zu überlegen, um die Favorisierung eindeutig zu machen, den Tag mit building_colour… anstatt mit building:colour beginnen zu lassen.
Das würde auch zu einer komplett neuen Beschreibung führen, die ich gerne übernehme.
Anh.: Und wenn das ganze Haus so aussieht? Sagt man einfach an einem Punkt: building_colour:all_around … oder belässt es mit building:colour=*, wobei sich ersterer tag sich immer auf einen Punkt bezieht, nie auf der line.