Was sagen den die “Nutzer” der 3D-Daten? Sind nicht zwei getrennte (übereinanderliegende) ways einfacher zu handeln?
Ich würde (als Laie) verständlicherweise building=* für ein einfaches 2D abfragen. Die Daten (Beispiel Hausname) die dann hier hinterlegt sind, können zu weiteren Informationen ausgewertet werden. Eine Höhe oder Wandfarbe brauche ich hier nicht.
Für 3D würde ich nach building:part=* suchen und diese Daten auswerten. So würde es Sinn machen, building:part=* als “Zeiger für 3D” mit den weiteren 3D-Daten zu nutzen. Das ist auch für Gebäude geeignet, die sich aus mehrer building:part=* zusammen setzen. Für building:part=* liese sich auch (erweitert) ein Wert eintragen (yes, tower, wall, ruin, …). So brauchte ich für 3D nicht alle buildings abzufragen, ob sie weitere 3D-Daten beinhalten.
EDIT zu dem Beispiel Turm:
Für 2D wären nur die Daten building und addr:* wichtig. Hier habe ich aber auch alle Daten die 3D betreffen mit an dem way. Hier macht meines Erachtens eine Datentrennung beim Erfassen Sinn - und sind auch besser “einfach wartbar” - Adressänderung.
Rogehm,
dein Beispiel ist meiner Meinung nach falsch. Wenn diese Linie eine Gebäudeteil bedeutet, sollen daran KEINE building= und addr: stehen. Wenn diese Linie Gebäude bedeutet, sollen daran KEINE building:part= und **roof:**stehen. Wenn Gebäudeumriss und Gebäudeteilumriss gleich sind, sollen sie wie ZWEI übereinanderliegende Linien bezeichnet werden.
Und… Sorry, aber diese Beispiel ist über echte 3D-Building, und ich spreche über Haus, das EIN Teil hat.
Ich sehe zwar die Pragmatik hinter dieser Auftrennung, ganz ohne Nebenwirkungen ist das aber nicht:
Es gibt dann zwei Objekte (building und building:part) für dasselbe physische Objekt. Wenn jemand auf “building” filtert und dann das Gebäude verschiebt, liegen nachher die beiden ways nebeneinander. Das kann bei “building:part identisch building” viel leichter passieren als bei “echten” :part, da die Linien ja vorher ununterscheidbar übereinander liegen.
So ganz intuitiv ist diese Auftrennung auch nicht, daher ja auch (stellvertretend) die Verständnisschwierigkeiten von edward17.
Nicht notwendig, sogar unter Umständen irreführend, wenn man z.B. die Anzahl der 3D Bauwerke zählen wollte.
ALLE Gebäude die nach S3DB getaggt sind,haben den Tag, roof:shape=*.
Die Suche nach diesem Tag ist zuverlässiger.
Überzeugt Euch selbst mit einem Test bei Taginfo.
Sollen sie diesen Tag haben? Oder einfach jeder, der 3D-Häuser malt, hängt roof:shape?
Wenn ich 3D-Häuser gemalt habe, habe ich diesen Tag nicht gestellt. Ein Beispiel: http://www.openstreetmap.org/relation/3469957
Wir müssen in S3DB roof:shape benutzen.
In Deinem Beispiel braucht man 4 verschiedene building:part=yes mit verschiedenen height=*. Alle building:part sollen roof:shape=flat haben.
Dazu noch eine runde Kuppel aus blauem Glass in der Mitte. Von der Kuppel, die auch ein building:part ist, haben wir noch gar nicht gesprochen.
Ein Hinweis: für uns ist eine Diskussion und Benutzung von Google Bilder nicht zulässig! Es sntspricht nicht unserer Lizenz.
Ich wollte nur Deine Frage beantworten, weil ich glaube, dass Du dort wohnst und kein Material von Google brauchst.
Ich weiß über Lizenz. Ich male Google Satellite Fotos natürlich nicht. Ich habe nur dazu diese Link geschrieben, um Dir zu zeigen, wie diese Gebäude im Realität aussieht. Ich wohne dort und kann dieses Haus ohne Google StreetView sehen und mappen.
edit: Jetzt ist es auch in F4 korrekt, nachdem das building nicht mehr gleichzeitig als building:part genutzt wird. Die 3D-Tags sind jetzt alle auf eigenen Ways.
Die Map war mir bisher unbekannt. Der Turm wird hier anders ( und genau? ) dargestellt. Aber irgendwie ist die Map noch schwer im Beta, oder? Nicht hier, aber sonst habe ich noch Probleme damit.
Ich hatte mir das Beispiel, das du jüngst erst getaggt hast, rein zufällig genommen, da ich, zumindest Nürnberg Altstadt recht gut kenne. Leider hat osm2world das noch nicht gerendert. Daher nur der Verweis auf F4.
Du machst sehr gute Arbeit! Was hältst du von dem hiesigen Thread, bzw. der Erkenntniss, die Aussenumrisse “abzukoppeln” vom 3D-Tagging ( also 2 Linien )?
Anh. @pyram: Sorry, du hast das schon in #26 beschrieben, aber beim Turm Aussenumriss hast du den Außenring gleichzeitig für den obersten Turmabschnitt benutzt.
Ja, einige 3D-Gebäude sind Versuchsgebäude um herauszufinden, was die verschiedenen Renderer akzeptieren. Wenn es eine Einigung gibt, dass man building:part nie an building=* tagged, dann passe ich das gerne an. Hoffentlich stört das dann auch JOSM nicht mehr.
Wir haben aber mehr solche Fälle, wo Linie auf Linie liegt (Zäune auf Landgrenzen manchmal am Haus angeschlossen, Stützmauer am Flußufer). Also wer da “filtert und verschiebt” (geht das überhaupt, wenn die nodes nicht getrennt sind?) sollte auch die angehefteten mit verschieben. Wenn zwei part in der Fläche building sind, sind diese auch über die nodes verbunden.
Ich verwende für diesen Zweck OSM2World in Kombination mit JOSM zur lokalen Darstellung. In Josm speichere ich meinprojekt.osm und rufe es mit OSM2World.jar auf. Eventuell gibt es einfachere Wege aber in Josm fand ich nicht funktionierendes. Für Screenshots ist es aber hilfreich.
Eine Überarbeitung bzw. Ergänzung der Seite wäre wünschenswert. Als ich mir die verlinkten Beispiele (z.B. Bremen) anschaute stolperte ich zufällig über roof:ridge, roof:edge … Im Wiki fand ich dann diese Seite.
Kennt jemand zufällig eine Kirche, welche in 3D umgesetzt wurde? Das Beispiel hilft mir nicht weiter, da ich das Dach dieser Kirche nicht hinbekomme. Es liegt vermutlich daran, dass der Turm in dieses “hineinragt”. Ganz zerstört wird das Dach, wenn ich noch das fehlende Türmchen auf dem Dach ergänze. Bin noch Anfänger auf dem Gebiet. Eventuell ist die Lösung ja einfach. Nebenbei schaffe ich es nicht einen Dachüberstand zu zeichnen… Falls jemand ein nettes Tutorial kennt wäre ich froh über einen Link zu diesem. Vermutlich gibt es einen anderen Ansatz als den von mir prakizierten. Vielleicht sollte man nur einzelne Dachflächen zeichnen? Wobei dies die Angelegenheit (für mich) noch unübersichtlicher macht.
Ich korrigiere mich: Da wird bei verbundenen Knoten die “unsichtbare” Linie mit verschoben. Passiert ja auch (als Unfall) z.B. bei Straße auf Grenze, wenn nur eines von beiden geladen wurde.
Nicht verbundene Knoten an der selben Stelle werden zwar vom JOSM-Validator angemeckert, können aber trotzdem hochgeladen werden. Andere Editoren sind möglicherweise noch großzügiger. Fehler sollten aber in Designüberlegungen nicht eingehen.
Ziehe meinen Einwand also zurück.