ich hab hab schon hin und wieder 3D-Tagging in OSM gemacht, und bin dabei auch schon mit diversen Viewern in kontakt gekommen. osm2world ist meiner meinung einer der besseren, weil er unter anderem auch relativ problemlos clientseitig läuft.
Da ich interresse an neuen technologien habe bin ich in letzter Zeit immer öfters mit WebGl in kontakt gekommen. Auch emscripten ist immer öfters in diesem Konzext darin vorgekommen. Was mich besonders am Anfang erstaunt hat war die enorme Leistungsfähigkeit dieses gespannes. Ganze 3d-shooter liefen im browser komplett flüssig (auch auf nicht so schneller hardware).
Was mich wundert ist dass ich zu WebGl im zusammenhang mit OSM nicht sehr viel finde.
Meine Idee wäre ein kompletten 3D-Renderer für den Browser, der die Daten mittels der OSM-Api abruft und dann direkt im Browser darstellt. Das ganze würde natürlich nur in den höheren Zoomstufen funktionieren, da ansonsten die Datenmengen zu groß werden würden.
Ich will jetzt einfach mal fragen was ihr von dieser Idee haltet? Ich finde das soetwas ganz neue möglichkeiten eröffnen würde.
Das Problem ist, dass WebGL nur für das 3D rendering auf der client-seite genutzt wird. Es muss dort entweder auch Daten interpretiert werden (also was OSM2World auch macht), oder der Server streamt sogar nur vorberechnete 3D Geometrien zum Client. Kurzum, da steckt leider eine etwas komplexere Infrastruktur dahinter, die ja möglichst auch von anderen Tools genutzt werden sollte.
Da das also etwas größer wird, gab es auch Überlegungen, ob man da nicht auch einen Codesprint machen könnte. Den GSOC gibt es ja auch noch
Client holt sich die OSM-Daten mittels der OSM-API
Texturen, 3D-Modelle für Briefkästen, Lampen,… werden von einem/mehreren Server bereitgestellt
Terrain wird mittels STRM-Daten erstellt (villeicht vorberechnet oder in ein passendes Format umgerechnet)
Das Rendern von Gebäuden läuft Clientseitig ab, bei komplexeren Strunkturen könnte man villeicht auch Serverseitig modelle vorberechnen
Es soll so viel wie möglich der Arbeit auf dem Clienten ablaufen, um die Serverlast wie das Rendern, Vorberechnen,… möglichst zu sparen.
Die Texturen, 3D-Modelle sollen großteil ohne Codeänderungen erweiterbar sein. (Bei osm2world muss man meines wissen den code dafür umschreiben → weniger leute können mithelfen neue modelle, texturen einzubinden, sondern nur ändern)
Bassierend auf C++, und mit emscripten zu js-Umgewandelt → Integration in Web und Client/Server-bassierten Programmen möglich, mehr leute können vermutlich c/c++ (opengl), integration in z.B. Navi mit offline-Modellen&Texturen, Spielen,… (mehr möglichkeiten als rein js), …
Da hatte user:Tordanik mal einen ähnlichen Ansatz vorgeschlagen, vielleicht solltet ihr euch da mal austauschen?
/ 5. Ja Modelle im Code ist natürlich langfristig nicht so toll. Da würde mein Model Repository ja ansetzen, wenn ich denn mal dazu komme Trotzdem bergen auch externe Modelle noch etliche Fallstricke
Da soll mit OpenDEM ja was passieren, derzeit ist Martin da aber wohl sehr ausgelastet. Vielleicht kann man insgesammt eine Kooperation mit www.osm-3d.org von der Uni Bonn anleiern? Im Prinzzip wurde das ja mit dem xml-3d Client gemacht, der WMS-3D implementiert
Verstehe, allerdings sind dann embedded-Geräte definitiv raus. Die Serverlast 1:1 an die Overpass-API durchzureichen halte ich für ein bißchen gewagt. Infrastruktur muss ja eh aufgebaut werden, dass geht in meinen Augen nicht alles realtime client-Seitig was OSM2World derzeit macht.
Das kenne ich noch nicht gut genug, um da was zu zu sagen. Allerdings ist das Navi-Umfeld stark heterogen. Ich würde fast behaupten, dass die schon glücklich sind, wenn die eine API oder Dump hätten, über die sie S3DB konstruierte einfache 3D Modelle für besondere Gebäude ziehen könnten
Das währe mal einen versuch wert. Ich kann derzeit aber leider noch kein OpenGl/WebGl. Meine Idee wäre: Man lädt ein Geländemodell mit variabler größe und setzt immer mehr Häuser und 3D-Modelle rauf bis es zum stocken anfängt. Dann hätte man einen ersten anhaltspunkt was WebGl schafft. Die Leistung die zum erstellen des geländes eigentlich nötig wäre ist da dann nicht wirklich enthalten, aber man wüsste dann wie viele Daten insgesamt ungefähr renderbar wären.
opendem schaut interressant aus, nur glaube ich dass die aktuellen daten nur für deutschland sind. Hab aber nur kurz darübergeschaut
Da müsste man dann schauen, ich würde es so machen dass man unterschiedlich rendern kann, und embedded-Geräte z.b. nur LOD-1-Modelle Rendern (was sicher nicht sehr komplex sein wird, im gegensatz zu dächer rendern). Ich finde man sollte sowieso alles sehr modular aufbauen, und schwachen Geräten auch nur kleinere Gebiete, weniger modelle (weniger detailtiefe),… geben.
Mein problem ist dass ich derzeit nur Mappe, und erst eine einfache OSM-Anwendung geschrieben habe, die ich demnächst wegen (css-fehler/ etwas unverständlicher programmcode) nochmal neu machen werde. Grafikprogrammiermäßig hab ich nur erfahrung mit SDL. Dafür besitze ich schon Erfahrung mit etwas komplexeren C+±Projekten (>3000 Zeilen Programmcode), und diversen JS/PHP Sachen. Also alleine werde ich da nicht weit kommen. Die Frage ist nun wie viele leute interresse daran hätten und wieviele auch mithelfen würden.
Ich finde die Idee auch sehr interessant! Allerdings bin ich wie !i! etwas skeptisch, was die komplette Verlagerung der OSM-Auswertungslogik in den Client angeht. Zum einen ist das eine Frage der Performance, aber natürlich wäre damit auch ein beträchtlicher Programmieraufwand verbunden - ich habe selber beim Entwickeln von OSM2World gemerkt dass da einige Arbeit drinsteckt, und das müsste man dann ja praktisch alles noch einmal neu bauen. Schon dein Punkt “Terrain wird mittels SRTM-Daten erstellt” ist komplex genug, dass ich derzeit eine komplette Masterarbeit darüber schreibe, und auch für unzählige andere vermeintlich kleine Details (Multipolygone, Coastlines, Straßenspurtagging, Bäume die nicht auf Waldwegen stehen, Sonderfälle bei den Dachberechnungen, Gebäudedurchfahrten, …) muss man sehr viel Zeit einplanen.
Vielleicht also doch erst einmal damit anfangen, auf dem Server vorberechnete Modelle mit WebGl zu zeichnen? So kämst du wahrscheinlich vergleichsweise schnell zu ersten guten Ergebnissen. Danach kannst du auf dieser Grundlage dann Schritt für Schritt ausprobieren, bei welchen Objekten es Sinn macht, die Berechnungen in den Client zu verlagern. Dabei wäre man dann auch nicht mehr auf Vermutungen angewiesen, sondern könnte an einem realen System testen.
Falls du diesen Weg gehen möchtest und dazu auf der Serverseite OSM2World in Frage käme, würde ich das gern mal mit dir diskutieren.
Also, das ist zwar momentan richtig, soll aber nicht so bleiben. Ich will eigentlich dahin kommen, dass sich Texturen, Materialeigenschaften und fertige 3D-Modelle (also solche, die etwa in einem Modeller erstellt wurden) in OSM2World ohne Bearbeitung des Codes ändern, aber auch hinzufügen oder entfernen lassen.
Was ist dabei das große problem? Das Terrain direkt zu rendern ist eigentlich nur ein Gitternetz zu erstellen und die Höhenwerte+koordinaten zuzuweisen, oder irre ich mich dabei. Diese Daten dann mit anderen Daten zu verbinden um bessere Daten zu erhalten wie bei OpenDEM ist was anderes, aber dafür gibt es OpenDEM ja auch.
Was von interresse wäre ist, wenn jemand mit 3D Spieleentwicklung-Erfahrung mithilft. Ich glaube dass das das hier viel mit der Spieleentwicklung gleichzusetzen ist. Terrain, Texturen, Rendering, Modelle.
Wenn dir das reicht, ist es vergleichsweise einfach, klar.
Bei mir geht es eher um Sachen wie die Integration von Tunneln/Brücken/Einschnitten… ins Terrain, die Interpolation von glatten Kurven zwischen den relativ groben Gitterpunkten und die Berücksichtigung von Zusatzinfos, damit Treppen z.B. in die richtige Richtung gehen, Wasserflächen nicht schief sind und Flüsse nicht aufwärts fließen.
Die anderen Beispiele, die ich oben genannt habe, sollten aber denke ich auch für deine Zwecke größtenteils relevant sein. Es ist schon etwas Aufwand, aus OSM-Daten ordentliche 3D-Modelle zu berechnen.
Das stimmt.
Ich schau mir mal glosm an. Von den Eckdaten würde es genau passen, und man müsste dann nicht alles neu entwickeln. Ich wollte mich sowieso schon mal mit OpenGl auseinandersetzen, das würde genau passen.
Die Schwierigkeit dürfte hauptsächlich darin bestehen Objekte so zu zeichnen, dass sie genau auf dem Terrain liegen und nicht etwa darunter verschwinden.
Es gibt noch ein paar mehr Sachen, die OSM mit WebGL nutzen:
