Im wiki-Eintrag Simple_3D_Buildings ist unter #Roof noch kein Eintrag zu roof:ridge=yes und roof:edge=yes.
z.b. http://map.f4-group.com bezieht sich auf diese Seite und darum werden roof:ridge=yes und roof:edge=yes dort nicht unterstützt: https://getsatisfaction.com/f4map/topics/wrong_roof_form_and_colour
Im Normalfall würde ich im wiki ja einfach solche Sachen ergänzen. Aber bei 3D-Sachen ist es doch eher heikel.
Von daher: was haltet Ihr davon, diese beiden Tags einzutragen?
Ich bin dafür.
Eine generalisierte und trotzdem möglichst realitätsnahe Abbildung der Realität erreichen wir nur, indem wir beide Herangehensweise unterstützen.
Jetzt kommen wir wohl allmählich an den Punkt, wo wir uns einigen müssen, was “Simple 3D Buildings” eigentlich sein soll, und ich fürchte da hat jeder eine andere Perspektive. Ich beschreibe mal meine Sicht:
Simple 3D Buildings ist nicht die Gesamtheit aller Tags mit 3D-Bezug in OSM. Bei Simple 3D Buildings geht es stattdessen speziell um die Beschreibung von Gebäuden über Tags an den Gebäuden und Gebäudeteilen, nicht z.B. über zusätzliche Ways. Natürlich sollten auch bewährte Konzepte, die nicht Teil von Simple 3D Buildings sind, von Anwendungen unterstützt werden, und Roof Lines sind wohl ein solches bewährtes Konzept. Aber das heißt nicht, das diese erweiterten Konzepte dann Teil von Simple 3D Buildings werden und auf derselben Seite dokumentiert werden – sonst wird die Seite ja auch dem “simple” im Namen bald nicht mehr gerecht.
Was die Dokumentation angehen würde, denke ich daher eher, dass das Roof-Line-Konzept auf Buildings#3D in einem zweiten Satz erwähnt und verlinkt werden sollte. Auf der Seite zu Simple 3D Buildings ist es unter roof ja bereits verlinkt.
Dafür!
OSM2World wertet beides aus (und ich benutze es intensiv). Damit lassen sich Dachformen sehr viel leichter genau beschreiben als auf die umständliche Art mit Parametern für Richtung und Neigung. Insbesondere wenn Dächer asymmetrisch und/oder unregelmäßig gebaut sind, sind diese beiden Linien sehr hilfreich. Beispiel dieser Kindergarten bei OSM2World (das helle Gebäude ca. in der Mitte).
Ich würde das einfach mal auf der Diskussionsseite von Simple_3D_Buildings zur Sprache bringen.
Die beiden Linien sind bei User:Aschilli/ProposedRoofLines vorläufig definiert.
Edbert (EvanE)
Ich bin auch der Meinung, dass “Simple 3D Buildings” so simple sein soll wie möglich - ohne Schnick Schnack. Aber genau diese beiden Linien roof:ridge=yes und roof:edge=yes würde ich persönlich noch als Simple einstufen (das ist meine Meinung, aber wie Tordanik schon sagte, gehen da natürlich die Meinungen auseinander). Vorallem kann man mit diesen beiden Linien doch einiges einfacher darstellen bzw. einiges darstellen, das sonst nicht möglich ist.
Nun ja mit building:part=yes sind ja bereits zusätzliche Wege definiert.
Ich finde die Roof-Lines sehr viel einfacher und übersichtlicher als die Definition über mehrere Parameter. Letztere müssen bei unregelmäßigen oder asymmetrischen Dachformen in der Regel scheitern und braucht dann doch entweder zusätzliche Linien oder zumindest Stützpunkte.
Zumindest sollte (wie du vorschlägst) etwas mehr zu den Roof-Lines im Artikel Simple 3D Buildings erwähnt werden. Nach meiner Einschätzung gehören der Dachfirst und die davon abgehenden Kante sehr wohl zu Simple 3D Buildings, da sie (wieder nach meiner Meinung) einfacher und da explizit auch übersichtlicher sind als viele zusätzliche Parameter.
Auf jeden Fall bin ich froh, dass ihr die Roof-Lines in OSM2World unterstützt. Ein Beispiel habe ich ja in meinem vorigen Post (#4) bereits verlinkt.
Um es zusammen zu fassen:
Ich bin dafür, die Roof-Lines (zumindest Dachfirst und Dachkanten) in Simple 3D Buildings aufzunehmen.
Edbert (EvanE)
Ich habe mich schon geäußert: selbst ein simples Modell muss ein Mindestmaß an Wiedererkennungswert ermöglichen.
Natürlich kann man darüber diskutieren - wahrscheinlich sehr lang und erfolglos - wo “simple” endet,
wenn wir uns aber an der gängigen Praxis aus der 3D GIS Welt orientieren würden - Sprich an dem LOD Konzept, dann müssen wir Folgendes feststellen:
LOD 0 sind in der GIS Welt Gebäude mit dem Umriss und Höhe die als Multiplikator der Anzahl der Stockwerke mit einem Wert, z.B. 2,50 m pro Stockwerk die 3D Realität vorgaukeln. Das kann man mit OSM Modellen schon machen da wir die Anzahl der Stockwerke erfassen können.
LOD 1 sind Gebäude mit EINER Höhenangabe die der maximalen Gebäudehöhe entspricht - bei uns wäre das height=value für building=yes
LOD 2 sind Gebäude mit generalisierten Dachformen wobei man unter Generalisierung das Auslassen bestimmter kleineren Details versteht und nicht die Zurechtbiegung der Geometrie an eine Sammlung der Grundformen.
Die S3DB ist Pfiffig, denn die Definition ermöglicht die Erfassung der Mehrzahl der Dachformen. Für den Rest benötigen wir Roof-Lines. Dann sind wir mit unserer Erfassungstechnik mit der LOD 2 aus der GIS Welt völlig kompatibel.
Das ist für mich ein wichtiger Grund der für die Aufnahme in S3DB spricht.
Also ich bin nicht fundamental gegen eine Aufnahme, aber neben der Grundsatzfrage - wo genau ist eurer Ansicht dann die Grenze? - habe ich auch einige konkretere Bedenken:
Erstens bin ich nur dafür, die Linien zu benutzen, wenn es für ein bestimmtes Dach wirklich nötig ist - denn sonst verliert man semantische Informationen für Suchen und Filter und andererseits wächst die Datenmenge je Haus. Die Aufnahme in S3DB lässt sie aber als “gleichwertig” erscheinen, so dass mehr Mapper standardmäßig Linien einsetzen dürften. Eventuell könnte man da natürlich mit einer geeigneten Formulierung entgegenwirken.
Es gibt aber noch ein größeres Problem: Das Zusammenspiel mit den Dachform-Tags ist ungeklärt. Bisher sind Roof Lines (zumindest aus Sicht von OSM2World) eine direkte Alternative zu Dachform-Tags. Sprich, sobald Roof Lines da sind wird die Dachform ignoriert. Da müsste also noch geklärt werden, wie Roof Lines denn mit den anderen Teilen von S3DB zusammenspielen sollen. Kann ich z.B. nur eine Ridge einzeichnen und die Edges werden dann je nach Dachformtyp automatisch ergänzt?
Auch im Allgemeinen gibt es noch experimentelle Aspekte des Schemas, mit verschiedenen ungeklärten Fragen. Beispielsweise hat Aschilli erst vor einigen Monaten einen bedeutenden Aspekt verändert, der OSM2World inkompatibel zur (neuen) Definition macht. Da müsste man noch einige Details spezifizieren, um eine einheitliche Auswertung zu ermöglichen - die Roof Lines haben ja keine so gründliche Diskussion hinter sich wie das ursprüngliche S3DB, und diesen Qualitätsstandard würde ich schon gerne aufrecht erhalten.
+1!!
Stimmt! Was kann man dagengen tun?
Solltenwir in einem Arbeitsgespräch klären können. Was ich vielleicht nicht erwähnt habe:
Das Schema von Aschilli basiert (vielleicht ungewollt) auf der Spezifikation von dem Cyber City Modeller -Publications
Für diese Software habe ich vor vielen Jahren die Spezifikation entwickelt. Diese Spezifikation ist auf jedem Fall ausgereift, überprüft und eindeutig.
Sie bedeutet natürlich einen enormen Aufwand in der Umsetzung. Immerhin war sie an der ETH Zürich einer Doktorarbeit Wert und im Anschluss haben daran mehrere chinesische Doktoranden gearbeitet. Die Software war damals seiner Zeit eindeutig voraus. Schade für den Geschäftsführer, dass sich die Investoren zurückgezogen haben und die Firma Insolvenz anmelden musste. Trotzdem: Die Gedanken sind allgemeiner Natur und nicht patentierbar.
Vielleicht kann hier jemand mitmachen und dem Tordanik helfen?
Man könnte festlegen, dass (wie du im nächsten Abschnitt sagst) grundsätzlich ein “entweder oder” existiert:
Entweder die Dachform als roof:shape oder die Dachform per roof:ridge + roof:edge.
Weiter sollte man darauf hinweisen, das die Roof-Lines nur in den Fällen angewendet werden sollen, in denen das notwendig ist. Zum Beispiel bei unregelmäßigen Dächern (siehe Beispiel aus Beitrag #4) oder wenn ein Dach nicht symmetrisch ist, sprich ein Dachteil höher / steiler ist.
Ich bin durchaus dafür, Roof_Lines und roof:* Parameter als Alternativen zu betrachten. Diesen Aspekt hatte ich bisher noch nicht bedacht, aber er leuchtet mir ein.
Eine automatische Ergänzung von roof:ridge um die roof:edge halte ich beim Thema “Simple 3D Buildings” nicht für sinnvoll. Nur im Fall eines einfachen aber unsymmetrischen roof:shape=gabled reicht roof:ridge alleine aus, da es dann mit dem Umriss des Gebäude(teil)s verbunden ist. In den anderen Fällen braucht man die roof:edge Linien um diese Verbindung herzustellen.
Ja leider. Ursprünglich war roof:ridge als Dachfirst (also die höchste horizontale Linie in einem Dachteil) definiert. Mittlerweile darf das jede horizontale Linie sein, leider auch der Dachrand.
Nach meiner Meinung sollte für den Dachrand ein eigenes Tagg definiert sein, so dass diese zwei Dinge nicht verwechselt werden können. Nach dict.leo.org wäre roof:roof_edge die passende Übersetzung für Dachkante. Man kann natürlich auch wie Aschilli roof:cullis (für Dachrinne) verwenden. Allerdings hatte ich diesen speziellen Begriff vor Roof-Lines noch nie gehört. roof:roof_edge ist dazu im Vergleich selbst erklärend.
Nach meinem Empfinden sollten wir es bei Simple 3D Buildings für roof:ridge bei Dachfirst belassen. Die anderen (in meinen Augen unglücklichen Alternativen) sollten nicht unterstütz werden. Insbesondere sollten andere horizontale Kanten mit einer eigenen Bezeichnung versehen sein.
Edbert (EvanE)