Workshop OSM 3D

Freut mich dass es euch der Vorschlag gefällt. “3D Workshop” ist vlt. ein wenig ungenaue beschreibung, da ich eigentlich eher ein Treffen von Entwicklern meine, die sich mit 3D beschäftigen. Die Frage des WO ist da für mich eher zweitranging, wichtiger fände ich da schon die Inhalte die dort diskutiert werden sollten:
-mal alle 3D tags die so rumschwirren auf einen Tisch packen, mal eine Feature Matrix, welches Tool welche Tags verwendet und ggF. angleichen, damit es einigermaßen konsistent wird
-damitmal ein paar 3D Demo-Regionen erstellen, die Entwicklern als Testbett und Mappern als Vorlage dienen können
-daraus mal einen Artikel für den OSM Blog machen, um Leute etwas an die Hand zu geben und zu ermutigen sich auch in die 3. Dimension vorzuwagen
-Wir können wir OpenDEM unterstützen, damit nicht jeder Client SRTM sleber verarbeiten muss und es einen Service gibt, der Geländekacheln anbietet? Wie können wir diese für Nutzer editierbar machen und Terrain-Mapping mit einfachen Mitteln realisieren?

Wichtig wären mir, dass wirklich sehr sehr viele der 3D Entwickler vorbeischauen und uns helfen einen Einblick in Ihre Projekte und Pläne/Probleme geben. Vielleicht auch, dass wir unsere Energie ein wenig besser bündeln und Informationen/Dienste zentraler dem Thema 3D zuordnen und nicht unbedingt einer einzelnen Anwendung
-OSM2WORLD - Tordanik
-OSM3D - Aschilli
-OSM2POV Bitsteller, Aleš Janda(CZ)
-OSM4D - Marek
-OpenDEM - Martin Over
-GLOSM - AMDmi3 (RU)
-Kendzi3d - Kendzi (PL)
Ich habe ehrlich gesagt keine Ahnung, wie man die ausländischen Entwickler da effektiv gut mit an den Tisch kriegt. Entweder man probiert sie irgendwie her zu bekommen (wobei der Aufwand immernoch groß ist) oder man probiert das über 2-3 Videokonferenzen abzudecken.

Ja die Vorschläge sind ganz gut, allerdings teilweise schon recht weit vorausblickend, denke ich. Z.B. kann man Testbeds/Mapper-Vorlagen und auch OSMBlog-Artikel wohl sinnvollerweise erst dann machen, wenn entsprechend eine Übereinstimmung zu den Methoden und funktionierende Tools vorhanden sind.
Von daher könnten wir neben der Feature Matrix Geschichte auch überlegen, für welche methodische Ansätze alles Tools angeboten werden sollten, um da dann auch wirklich in die (gemeinsame!) Entwicklung zu gehen.

Ich kenne zwar noch nicht alle Details unser Web 3D Service Spezifikation, aber wenn mich nicht alles täuscht, bietet der W3DS bereits auch Geländeabfragen an!

Das stimmt natürlich und sind natürlich auch nur meine eigenen Ideen, andere werden andere haben. Es sollte (IMHO) sich ebend um die gemeinsame Schnittmenge gehen, die den meisten weiterhelfen würde. Von da an können viele Sachen parallel gestartet werden (bessere Wiki Doku, Blog Artikel als Mapper Aufruf, …)

Ja ihr habt auch das aufbereitete SRTM DEM drinne. Aber wir sollten (IMHO) probieren diese Daten und Dienste nicht nur für OSM oder Geoleute bereithalten sondern ebend auch für Künstler und andere Leute, die an der 3D Schiene näher zu OSM kommen werden. Ich weiß OSM-3D hat da eine andere Intention (Showcase für den 3D WFS), aber das wäre wohl am nachhaltigsten, so dass der Aufwand, der einmal betrieben wurde auch für andere innerhalb der Toolchain nutzbar ist. Ich persönlich würde da gerne OpenDEM vorrantreiben, aber da muss natürlich Martin sagen in welche Richtung er sein Projekt sieht.
Ich weiß, dass ist natürlich ein Idealbild und das wird auch nicht so reibungslos klappen. Dennoch sollten wir probierenbesser unsere (neudeutsch) Synnergien auszunutzen :slight_smile:

Eventuelle auch mal über den Tellerrand schauen und die diversen Entwickler von Sceneries für XPlane mit einbeziehen. Das dürften diejenigen mit der größten Ausdehnung an 3D-Szenen aus OSM-Daten sein.

Nur mal so eine Idee
Edbert (EvanE)

Ja das hatte ich auch überlegt Edbert und würde es auch absolut befürworten. Aber ich habe mich dann doch lieber selber gebremst, denn bereits die paar Sachen, die ausschließlich mit der Erfassung und dem 3D Workflow zusammenhängen zu absolvieren ist schon viel. Ich befürchte, dass wenn man dann noch Leute dazu holt, die die Daten “nur nutzen” wollen, artet das schnell in Chaos aus, weil die evtl. eher die konkreten Szenarios für ihre Anwendungen im Kopf haben. IMHO geht es noch immer um ein gemeinsames Zwischenlevel und das Etablieren eines einfach tagging-Konzeptes bei der OSM Community. Erst in einem zweiten Schritt, wenn das Steht und auch die Zusammenarbeit für ein Höhenmodell und einem 3D-Objekt Repository geklärt ist, macht es Sinn, sich um ganz konkrete Anwendungen einen Kopf zu machen, oder? Aber vlt. male ich mir das auch zu finster aus… :wink:

Hallo Edbert,
gute Idee. Ich kenne diese Community nicht: fällt Dir ein, wie wir die Leute dort erreichen könnten?

@ !i! - ich kann nur die Entwickler aus Polen ( Kendzi, TU-Lodz) einladen und dafür sorgen, dass sie kommen.

Das wäre super, wenn wir wenigstens einen noch dazu bekommen könnten. Ok lagern wir den Beitrag zur Organisation mal aus: http://forum.openstreetmap.org/viewtopic.php?id=14540

Ich denke, dass wir stets in der Gefahr sind, uns um uns selbst zu drehen. Sprich man/frau wird bei so einem spannenden Thema leicht betriebsblind.
Die Leute die Szenarien für XPlane entwickeln sind in ihrer XPlane-Welt wahrschenlich genauso betriebsblind wie wir in unserer OSM-Welt. Aber was die von OSM brauchen, um darauf Szenarien aufzubauen, dafür haben sie einen ziemlich klaren Blick.

Was Szenerie-Entwickler von OSM brauchen sind zwei Dinge:

  • Ein einfaches System für die Masse der Häuser, das leicht und schnell umgesetzt werden kann.
    Sprich zusammengesetzt aus einfachen Kuben und mit nur zwei Dachformen (Flachdach/Giebeldach)
    Das schliesst auch die meisten Hochhäuser ein.
  • Ein ausgefeiltes System für markante Objekte, Kirche/Dom/Münster, Türme, große Flußbrücken.
    Eben alles, an was man sich bei einem Sichtflug orientieren würde.

Die ausgefeilten Dachformen inklusive Verschneidungen und Dachgauben ist für diese Leute, die ja zig-tausende Häuser rendern wollen, uninteressant, außer eben bei den markanten Objekten. Überlege nur einmal wieviele aus der Luft gesehen ähnliche Häuser um einen der größeren Flughäfen wie Frankfurt, Berlin, München, Stuttgart, Köln, Hamburg usw. stehen.

Sprich die brauchen im Wesentlichen nur einfache Parametrisierungen, wie height / building:levels oder roof:shape vielleicht noch die Farbe von Wand und Dach, soweit das überhaupt verfügbar ist.
Auf die Art und Weise vertreten die nicht nur ihre ureigenen Interessen, sondern auch den Blickpunkt “einfaches Taggen für Basic-3D”. Der wiederum kommt der Mehrzahl der Mappern, die nicht speziell für 3D mappen wollen, sehr entgegen.

Edbert (EvanE)

Ja ich verstehe den use case denke ich schon. Und ja auch ich sehe bei der zunehmenden Komplexität eine Gefahr für das 3D Tagging (aber nicht nur dort). Daher ja mein Wunsch das mal zu vereinheitlichen und fürs erste in Form zu gießen. Ich denke, da die Tools ja klar sind, sollte es vorrangig darum gehen ebend diese Entwickler der Tools zusammenzubringen, will da aber auch keinen ausgrenzen.

Auf X-Plane bin ich durch die Wochennotiz aufmerksam geworden. Eine Suche dort liefert die Ausgaben 71, 59, 46, 40, 35 und 19.

Weiter gibt es ein X-Plane Wiki. Dort dürfte Scenery_Development die interessantes Ecke sein.
Als Einstieg vielleicht noch die Einführung von Version 10 mit der Aussage “It’s all 3D” (vom Boden bis zum Orbit)

Ansonsten habe ich keine Verbindung in diese Welt.

Edbert (EvanE)

Ekhm,
ich denke dass dieses Treffen in der Tat notwendig ist: denn genau so wie Du schreibst, ist OSM4D konzipiert! Mit dem einfachen Unterschied dass bestimmte Dachformen eaus der Roof table beim Export in andere Systeme entweder als Flachdach (etwa die 0.n Gruppe) oder als Schräg bzw Doppelschrägdach exportiert werden können. Für solche Zwecke sind solche parametrischen Objekte geradezu genial: in Abhängigkeit von der Entfernung des Betrachters kannst Du sie modifizieren und anders darstellen, bzw. gleich so exportieren, wie es dir lieb ist.

Nicht vergessen: Das Konzept wurde entwickelt basierend auf langer Erfahrung mit Handhabung großer Datenmengen für relativ (im Vergleich mit PC) leistungsschwachen Navi Geräten.

Ja aber Marek, mir selbst geht es ein wenig wie EvanE, OSM4D kommt mir auch sehr komplex vor. Ich habe bisher noch nicht sehr viel gelesen, das ist nur mein erster Eindruck. Vielleicht muss da einfach auch nur mal die Doku umstrukturiert werden und sich auf weniger beschränkt werden, müssen wir mal schauen.

Wegen dem Treffen und ob wir X-Plane dazu ermutigt kriegen, bitte im 3D Forums Teil weiter diskutieren :slight_smile:

Klar ist es umfangreich, dabei ist es noch nicht alles…
Würdest Du OSM 2D auf einer Wikiseite darstellen wollen sähe es aber ähnlich aus… Daher ist auch ein Kick off wichtig, um die Grundidee zu besprechen, diskutieren und entsprechend zu sortieren.

Ja genau die Sicht des Mappers (der nicht ständig nachschlagen will) und die Sicht von Leuten, die ganze Städte und Landschaften aus ggfs. großer Höhe darstellen wollen, kommen in dem Punkt einfaches Tagging meiner Einschärtzung nach zusammen.

Edbert (EvanE)

Was es noch braucht und was ihr vielleicht bei eurem Workshop besprechen könnt, ist die Zuordnung vom einfachen Tagging zu Standard-Definitionen als einfacher, sanfter Übergang.

So etwas wurde bei dem neuen Public-Transport Schema auch notwendig. Das haben wir am Anfang nicht sofort gesehen. Aber als es jemand zur Sprache brachte “Wie gehen wir mit existierenden (alten) Tagging um?” wurde die Notwendigkeit einer Festlegung “Altes Tagging wird unter den und den Randbedingungen so oder so interpretiert.” schnell offensichtlich.

Edbert (EvanE)

Guter Hinweis. Grüße,
Marek

Hallo,

ich möchte bitte nochmal in Erinnerung rufen wo wir sind. Das ist OSM. Hier kann jeder das machen was er möchte und jeder macht es so detailiert wie er möchte.

Also Beispiel ÖPNV! Wir sind doch nicht böse darüber, wenn jemnad Haltestellen einträgt aber nicht die Informationen ergänzt welche Linie dort fährt oder in welche Tarifzone diese liegt.
Wir freuen uns über jeden der eine Buslinie einträgt, egal ob nach dem neusten Schema in mehrfach verschatelten Relationen oder erstmal nur am Stück alle Wege und relevanten Haltestellen.

Bei anderen Objekten sieht es genau so aus!" Wir freuen uns über jeden neuen Weg. Auch wenn noch nicht der surface die Maxspeed und maxheight oder Parkstreifen eingetragen sind.

Genauso wird es in 3D werden. Es gibt Menschen die erfassen die Höhen und Stockwerke. Andere erfassen die Dachformen nach der Rooftable oder nach dem System von Tordanik. Wieder andere hätten gerne noch den Balkon und die Wand und Dachtextur.

Und falls ihr das alles nicht glauben wollt. Wer hat zu letzt eine TMC Relation erstellt? Ich denke wir sollten den Einstieg mit geringen Hürden versehen, aber wir sollten nicht versuchen die Wirklichkeit so stark zu vereinfachen! Die Definition sollte soviel wie möglich Realität erlauben. Wie tief jemand eintaucht entscheidet jeder selbst und hängt neben seinen Interessen maßgeblich von den Bearbeitungswerkzeugen ab.

In Josm muß man diese Tags alle von Hand anbringen. Vielleicht gibt es später auch mal Vorlagen, aber schon die Namen für die vielen Dachtypen sind einfach nur schwer auseinander zu halten.
Ich denke das sollte ein Baukasten mit Vorschaubildern sein, wo sich der User wie bei einem Websitebaukasten nach dem Motto WSIWYG das Gebäube zusammenklickt. Das in Tags umzusetzen ist Sache der Software nicht Sache des Nutzers. Daher bin ich der Meinung, dass nur wenig davon die übrigen Nutzer der Datenbank belästigen sollte!

Das hast du so super zusammengefasst viw, gerade TMC zeigt dass man nicht zu komplex werden sollte. Ich füge das im englischen Thread noch ein. Bitte lasst uns jetzt aber wirklich dort weiterdiskutieren, da ich die ausländischen Leute da nicht ausgrenzen möchte.

Dann hast du meine Intention nicht verstanden. Ich denke 3D ist ein Beispiel für die Modellbildung der Wirklichkeit.
Wie hat mein Chemielehrer gesagt? Es gibt verschiedene Modelle für Atome. Wir verwenden jeweils dasjenige mit welches so einfach wie möglich ist, aber mit denen wir unser Problem erklären können.
Einige Menschen sehen bei 3D sicherlich nur wenige Dachformen. Andere sehen dort eben mehr Details. Beiden sollte man die Mitarbeit ermöglichen. Vor wenigen Monaten wurde man noch ausgelacht, wenn man man Bäume erfasst hat. Heute gibt es nicht nur die Unterscheidung in Laub und Nadelbaum, sondern ganze Kataloge.
Bei den Öffnungszeiten ist es genau das gleiche. OSM ist überall so. Erst muss es da sein. Das machen hoffentlich viele, dann wird es immer mehr verbessert und spezialisiert.
Es gibt zum Beispiel Wünsche Straßenbreiten und Fahrspuren zu mappen. Andere wollen lieber Gleise und Bahnsteige.

Achja und TMC ist nicht kompliziert. Es sind nur Relationen mit vielen vielen Nummern. Eigentlich ist es fast eine Buslinie nur das die Haltestellen keine Namen haben.

Erste Stufe:
Ich fand den Vorschlag von Tordanik - http://tobias-knerr.de/upload/RoofGallery.png - mit den Dachformen am einfachsten. Dazu die Höhe des Gebäudes und die Firstlinie könnten sicher “viele” leicht machen. Das als erste Form eines 3D-Mappings.

Zweite Stufe:
Wenn dann spezielle Dinge (Gauben, gewinkelte oder zusammengesetzte Dachformen) sollte dies ähnlich http://wiki.openstreetmap.org/wiki/User:Aschilli/ProposedRoofLines weitergeführt werden. Dies wäre dann schon eine intensivere Beschäftigung. Baut aber auf die Vorstufe auf. “Einige” würden sicher so mappen.

Dritte Stufe:
Die “speziellen” Dinge, wie von Marek - http://wiki.openstreetmap.org/wiki/DE:Roof_table#Exkursion.2C_Methodenvergleich - finden sicher “wenige” als anspruchsvolle Aufgabe. Aber gerade deshalb, sollte sie auf die vorhergehenden aufbauen.

In - http://wiki.openstreetmap.org/wiki/DE:Roof_table#Exkursion.2C_Methodenvergleich - ist schon ein Vergleich Tordaniks Dachformen zu 3dr von Kenzi. Diese “Tabelle” sollte “festgeschrieben werden” und als erste Form genutzt werden. {shed bei 1.0 sollte raus, da schon als Gebäude=Stall} (Dann könnte ich mir das als “Winteraufgabe” in meiner Gegend vorstellen - eventuell mit der “zweiten Stufe” zusammen.)


Vierte Stufe:
4D …