Ich gebe dir recht, wenn der Grundriss eines Gebäudes, also auch die Standardeingabe in die OSM, nicht kompatibel ist mit dem 3D Mapping.
Im 3D Mapping ist der Grundriss die grösste Ausdehnung in der Höhe.
Gut zu sehen am Rheinturm in Düsseldorf in der F4.
Das Tagging von kleineren Grundrissen (besonders erkennbar in Fernmeldetürmen) in der normalen Erfassung der OSM unterscheidet sich also grundlegend vom Tagging in 3D. Das ist ein schwieriges Problem, nicht nur bei Fernmelde-/ Fernsehtürmen, auch in der Wohnungsarchitektur gibt es Probleme, wie hier in Frechen das “schiefe Haus”.
So wie ich das verstanden habe (und was auch Sinn macht, wir malen ja oft von Luftbildern ab und kennen die Gebäude nicht) wird generell die projizierte Fläche als “outer shape” verwendet und als building:yes eingetragen. Alles was sich innerhalb befindet und als Building:part getaggt wird, wird so automatisch dem Gebäude zugeordnet. Der “Grundriss” ist dabei vollkommen egal!
Selbst bei den Beispielen mit den schrägen Gebäuden, wird die projizierte Fläche selten die Straße treffen. Und selbst wenn? Leitet mich mein Navi um das Gebäude rum? Nein. Das richtet sich nach der Straße.
Gruß,
Daniel
okay, nur offiziell ist building=* ja schon als Grund-Fläche definiert, oder nicht?
Klar, man könnte umdefinieren zu “größte Ausdehnung des Gebäudes, gemessen an allen seinen Teilen”, wonach das 3D-Rendering mit dem benötigten outer-building-Ring ja schon irgendwie schreit.
Im Prinzip bräuchten wir dann aber zwei Keys:
Einen für den Way, der die Gesamtausdehnung beschreibt (3D-Renderer), und einem für den, der nur die Grundfläche beschreibt. Okay, man kennt die Grundfläche nicht immer. Aber wenn sich diese unterscheidet von der Gesamtausdehnung und man das weiß, sollte man das doch kenntlich machen können.
Und das mit dem “Gesamtfläche” abzeichnen von schräg gebauten Gebäuden kann man aus meiner Sicht nur, wenn die Luftbilder quasi gerade aufgenommen wurden. Sobald Schrägaufnahmen ins Spiel kommen, wüsste ich nicht wo man da noch 'ne Chance hat.
Ich tagge 3d Gebäude immer mit allen Bestandteilen in einer Relation. Somit ist dort schon klar angegeben welche Teile zusammengehören. Die Outline kann für klassische 2d Karten verwendet werden und die Parts unabhängig davon für 3d.
Die Praxis hat zwar den Nachteil, dass die Daten so schwerer zu warten sind und verschiedene Gebäude die sich building:parts teilen nicht möglich sind. Dafür sind die Daten einfacher auszuwerten.
Andere OSM 3d Software stellt auch building:parts dar, die nicht im Grundriss liegen.
Hier ist ganz gut beschrieben was F4 darstellt und was nicht. Dort sind die Regeln für den Umriss extra mit “We are based on OpenStreetMap simple 3D building specification - over that base:” angegeben. Dann ist ja eher die F4map nicht Standardkonform?
Ich schätze 3d in OSM ist einfach eine zu kleine extrem komplexe Nische um dafür alle Eventualitäten auf einen guten Konsens zu kommen.
Ja damit ist dann klar welche Gebäudeteile zusammengehören. Das wird dann wichtig wenn man z.B. ein Geländemodel in die 3D Karte hinzufügt und dann die Höhe der Einzelteile bestimmen muss… Also alles was in einem “outer shape” ist hat einen gemeinsamen 0-Punkt.
Was schon bei Doppelhäuser bzw. Reihenhäuser ein Problem wird… Die müssten dann anders erfasst werden… aber ich will ich keine Grabenkämpfe anstossen 
Vielleicht aber… eher der Standard lässt viele Dinge offen und sagt nicht wie was gemacht werden muss ist daher unvollständig. Hier geht F4map vorweg und zeigt wie es erfolgreich gemacht wird, was alle anderen nicht schaffen. Alleine roof:orientation=along/across mach jede 3D-Karte anders… was äußerst blöd ist. Hier bräuchte es definierte Algorithmen, Vererbung, Fehlerbehandlung, usw. 
ich finde F4 map toll… 
ich versuche das mit meinem kleinen Städtchen… einiges ist schon fertig, der Rest kommt jetzt nach und nach…
https://demo.f4map.com/#lat=52.5310358&lon=12.3484755&zoom=16&camera.theta=61.902
Für 3D-Rendering ist Simple 3D Buildings eigentlich schon weitestgehend Konsens. Demzufolge sollten alle building:part komplett innerhalb der building-Fläche liegen. Was passiert, wenn ein Mapper von dieser Konvention abweicht, ist nicht spezifiziert – da kann jeder Renderer machen was er will. Soweit ich sehe, tritt keiner der in der F4-Doku genannten Fälle ein, wenn man sich an S3DB hält. F4 ist insoweit also standardkonform.
Das Problem kommt eher aus der 2D-Welt, bzw. aus unterschiedlichen Anforderungen zwischen 2D und 3D.
Habe durch Anregungen hier wieder etwas in 3D ergänzt. F4 ist aber momentan eingefroren, d.h. neue Eigenschaften werden nicht mehr gerendert, sowohl 2D als auch in 3D. Weiß jemand Genaueres?
edit: Die Aktualisierung hängt etwas. Momentane Aktualisierung läuft ca. eine Woche hinterher.
Ich hatte schon vor einiger Zeit ein paar markante Gebäude meiner Gegend gemappt. Leider wird hier: https://demo.f4map.com/#lat=48.8042397&lon=9.5299753&zoom=20&camera.theta=48.209&camera.phi=-116.199 die Dachform etwas missinterpretiert. Oder habe ich einen Fehler gemacht?
Was ist das: https://www.openstreetmap.org/way/638861565 ?
building:levels=1
…
building:min_level=-1
…
?
Die unterirdischen Gewölbe … ? 
Edit: Ach nein - laut Foto Hanglage unterhalb Eingangs- bzw. Straßenniveau.
Ich habe jetzt nicht in die Merkmale geschaut - wird sicher gabled sein? Ich denke es liegt an dem Modell des Renderns der Dachform wenn Unsymetrien ins Spiel kommen.
Hier habe ich auch so einen Kandidaten.
Da wird es nur helfen jedes Dachteil einzeln zu mappen.
Unterirdische Gewölbe hat es auch, die dürften vielleicht noch ein paar Level tiefer gehen. Das Burgschloss hat teilweise noch einen Graben ringsumher, so dass das Kellergeschoss on the ground sichtbar ist. Daher schon Mal für eventuelle künftige Datenmodelle das sichtbare UG vorgesehen.
trotzdem kann es nicht an einem way geben:
building:levels=1
building:min_level=-1
Wenn es underground ist dann building:levels:underground=1
Der Graben ist dann sicher auch schon -1 → damit ist das sichtbare Gebäude(teil)
building:levels=0
building:levels:underground=1
OK, das underground hab ich übersehen oder andes interpretiert.
nö, warum und wie sollte er -1 sein? Hab noch keine Möglichkeit der Geländemodellierung gefunden.
-1 heisst unterhalb etwas anderem, was darüber ist. Brücke vs Tunnel mal als Extrembeispiel.
Meiner Meinung nach war das vor 4 Jahren auch schon so, teils hat er in 2 Tagen aktualisiert, teils nach einer Woche oder 14 Tagen. Einfach ein wenig Geduld haben. - Die F4-Group braucht ja die Rechenleistung Ihrer Rechner und Netzwerke vor allem für Ihre kommerziellen Anwendungen. OSM ist für die F4-Group ja nur ein Demonstrationsvehikel, was Ihre Software so kann.
So isses. Aber der Rechner holt schon langsam wieder auf und hängt (momentan) nur noch um rund 100 Stunden (vier Tage) hinterher:
http://munin.self-perfection.homeip.net/munin/external/web/f4map_lag.html
In einer Woche könnte es wieder “live” werden.
