War bei mir auf meinem Dual-Athlon (3,1 Ghz) und zugeteilten 6 GB RAM (Linux) in 4 min mit einem 6 Mb *.osm-File fertig, nur bedienen konnte man das Programm so gut wie nicht, weil nach 3 min woll te ich nicht mehr länger auf das Erscheinen des view-Menüs warten…
Inzwischen gibt es eine neue Version: OSM2World 0.1.5
Viele der neuen Features greifen Anregungen auf, die ich hier oder als direkte Reaktion auf diesen Thread erhalten habe:
-
die meisten der “Balken bleibt stehen”-Probleme werden ab jetzt erkennbare Fehlermeldungen anzeigen
-
Trackpadnutzer können sich darüber freuen, dass man außer mit dem Mausrad auch mit den Tasten +/- zoomen kann
-
wem die Farben im Rendering nicht gefallen, der kann sie über eine Konfigurationsdatei ändern
-
building:min_level wird ausgewertet
Einige weitere Ideen, die ich auch selbst gerne sehen würde, habe ich bisher nicht umsetzen können - teilweise handelt es sich hier auch um längerfristigere Aufgaben. Dazu gehören:
-
sinnvoller Ausgleich zwischen getaggten und geratenen ele-Informationen
-
bessere Performance der Echtzeitdarstellung
-
deutschsprachige Bedienoberfläche
-
überarbeitetes Logging von Fehlern
An euch alle schon vielen Dank für die bisherigen Rückmeldungen!
Das sieht schon mal gut aus. Hier kann man sich das mit dem building_level mal anschauen: http://www.openstreetmap.org/?lat=51.375397&lon=12.752412&zoom=18&layers=M (Für einen besseren räumlichen Eindruck müsste ich aber die Betonpfeiler auf denen die Gebäudeteile stehen, noch einzeichnen.)
Also mir wäre es fast am liebsten, wenn man auch min_height nutzen könnte da das Gebäude Terrassenteile besitzt, die sich zwar im 1 .Geschoss befinden, aber dort nicht als überdachtes Gebäude ausgeführt sind: http://www.openstreetmap.org/browse/way/106303854 (Ich könnte zwar auch tricksen und 7 building level mit building:min_level=5 angeben, aber das möchte ich eigentlich nicht)
liegt an dir wie wichtig du die Sache einstufst: Die Notfluchttreppen werden durch das min_level nicht mehr mit dem Gebäude verknüpft, obwohl sie per Node damit verbunden sind. (sicher schwierig, wollte es nur gesagt haben). Kannst du building=entrance irgendwie kennzeichnen?
Ein interessantes Beispiel, ich werde die Gegend jedenfalls in meine Sammlung von “ab und zu mal nachsehen, ob so etwas schon funktioniert”-Testfällen aufnehmen.
Für einige deiner Details muss ich dich auf die schon länger geplante umfangreiche Erweiterung der Stockwerksberechnungen in OSM2World vertrösten. Dann sollten aber auch Dinge wie an einem Stockwerk ungleich 0 anschließende Wege/Treppen, Gebäude am Hang mit verschiedenen “ebenerdigen” Stockwerken je nach Seite und dergleichen mehr sauber funktionieren. Ist halt eine größere Sache…
Das sollte, je nach gewählter Lösung für die Darstellung jedenfalls, eine der einfacheren Aufgaben sein. Könnte ich mit etwas Glück bis Ende nächster Woche eingebaut haben.
(Ich versuche mich jetzt an einem wöchentlichen Veröffentlichungs-Takt. Mal sehen, wie lange ich das durchhalte. ;))
Ab jetzt verfügbar: OSM2World 0.1.6
Große Neuigkeiten gibt es nicht, aber doch einige Problembehebungen und Unterstützung für zusätzliche Tags:
-
Szenen mit einer Mischung aus Objekten mit und ohne ele-Tag liefern jetzt einigermaßen brauchbare Resultate
-
Unterstützung für building=entrance und min_height=* ist eingebaut
-
mit JOSM lokal geänderte Dateien wurden bisher nicht immer korrekt eingelesen, das wurde behoben
-
wenn der Konvertierungsvorgang abgebrochen werden muss, wird das dem Benutzer jetzt zuverlässiger mitgeteilt.
(Übrigens: Die etwas zu optimistische Idee mit den wöchentlichen Releases ist hiermit gestrichen.)
Schau dir noch mal die Schule an: http://www.openstreetmap.org/?lat=51.37535&lon=12.752504&zoom=18&layers=M
Die Betonpfeiler stehen teilweise in der Luft. Das Problem sind die Fluchttreppen, wenn man diese löscht, dann wird es wieder ordentlich dargestellt. Also irgendwas stimmt da nicht in Bezug auf Gebäude/Treppe und pedestrian darunter.
Der Gebäudeteil http://www.openstreetmap.org/browse/way/82600069 ist höher als die angrenzenden Gebäudeteile rechts und links, obwohl alle Gebäudeteile dieselbe Höhe haben. Auch hier ist der Fehler behoben wenn man die Treppe löscht. Ich denke mal hier müsste man die Treppe aber wirklich löschen, oder?
was muss ich tun, damit es unter mac os x 10.6.7 läuft?
Das Programm runterladen (z.B. in Downloads)
Terminal öffnen (über spotlight Terminal)
cd Downloads
cd OSM2World-0
chmod +rwx osm2world.sh
./osm2world.sh
cd Downloads natürlich nur wenn es da liegt.
Die Dateiangaben können im Terminal mit TAB automatisch vervollständigt werden.
Aufgrund der wöchentlichen Updates ist eine “Installation” in Downloads zum Anschauen sicher OK.
Edit: Ich habs auf einem 10.6.7 MBA getestet.
Edit2: Ordokraphy
Hallo Tordanik,
ich weiß nicht, ob es beabsichtigt ist, indoor Wege zu unterstützen, aber die folgenden Orte scheinen dein Programm ziemlich zu verwirren:
http://osm.org/go/0DKH1d4Xm–
http://osm.org/go/0GDzRtu77–
Vermutlich verwirrt die Nutzung von incline, weil scheinbar kein level ausgewertet wird…
Abgesehen von den Farben ist es sonst ein großartiges Programm!
OSM2World nimmt an, dass zwischen einem Verkehrsweg (bzw. einer Verkehrsfläche) und einer darüber führenden Brücke ein gewisser Mindestabstand bestehen muss, sonst könnte man ja nicht darunter durch laufen bzw. fahren. Der Abstand wird ggf. auf Basis von maxheight:physical, ersatzweise maxheight, vom unteren Objekt abgeschätzt. Wenn der Abstand nicht reicht, wird die Brücke mit allem was daran hängt nach oben gedrückt, das darunterliegende Objekt nach unten.
Diese Annahme ist üblicherweise auch sinnvoll und notwendig, denn sonst würde die Brückendarstellung überhaupt nicht funktionieren. Dein Fall gehört in die Kategorie von Situationen, an die ich dabei nicht gedacht habe. Schwieriger ist also die Frage, wie man das beheben sollte. Ein maxheight:physical an der Fläche und dem daneben verlaufenden Track würde für die Zwecke meines Programms funktionieren, wäre aber für den Großteil der Fläche natürlich falsch, und andere geeignete Tags kenne ich nicht. Vielleicht muss ich auch meine Annahmen überdenken. Eine eindeutige Lösung erkenne ich auch in dieser Richtung nicht. Ideen?
indoor-Wege sind als Feature geplant (erste Experimente gab es z.B. im Zusammenhang mit der auf der FOSSGIS 2011 kurz vorgestellten Gebäudemapping-Arbeit von Andreas Hubel), aber bisher nicht umgesetzt. Unansehnliche Ergebnisse sind daher leider momentan zu erwarten. Ich werde aber zumindest versuchen, die optischen Auswirkungen des fehlenden Features etwas abzumildern. Generell wird es übrigens schwierig werden, level auch dort auszuwerten, wo kein Gebäude drumrum ist.
Danke. Anscheinend mag keiner meine Farben. Ist aber ok: Ich mag sie selber nämlich auch nicht besonders. 
Es sei vorsichtshalber noch mal dran erinnert, dass man sie seit 0.1.5 per Konfigurationsdatei umstellen kann.
Eigentlich hätte ohnehin lieber Texturen statt der einfarbigen Flächen. Falls also jemand ein Talent oder für so etwas hat…
gehen ele-ways mit dieser Version?
Nur insofern, als das ele-Attribut von Ways an die enthaltenen Nodes übertragen wird, wenn diese selber kein ele haben und entweder der Node oder der Way gerendert werden.
In der nächsten Version sollen dann auch “unsichtbare” Ways verstanden werden, deren einziges Attribut ein Ele-Tag ist.
Danke, dann gedulde mich noch ein wenig
Ich habe jetzt an jeden Node der Treppe ein min_height getaggt, hört sich für mich logisch an. Der Rest wäre lineare Interpolation.
Hallo Forum,
Durch Stammtisch und diesen Thread habe ich mich auch mit 3D-Darstellung beschäftigt. Erste Ergebnisse sieht man hier:
Hannover Messe: http://www.openstreetmap.org/?lat=52.322799&lon=9.809473&zoom=18&layers=M
Las Vegas: http://www.openstreetmap.org/?lat=36.10641&lon=-115.17266&zoom=15&layers=M
Wenn man in Las Vegas nur die Gebäude rendert ist das Ergebnis gut. Mit allen Daten ergeben sich wilde Hügellandschaften.
Woher kommen diese Höhendaten?
Danke an Tordanik für die tolle Arbeit.
Robert
Hallo Robert, schön dass du in die 3D-Darstellung einsteigst. Das Thema ist spannend und kann fleißige Hände und kluge Köpfe gut gebrauchen. 
Zu deiner Frage: Höhendaten bezieht OSM2World derzeit ausschließlich aus OSM selbst. Dabei werden zum einen absolute Höhenwerte in Form des ele-Schlüssels berücksichtigt, zum anderen vor allem auch indirekte Hinweise wie incline-Tags und die Schlüssel bridge/tunnel + layer ausgewertet. Ansonsten wird mit allgemeinen Annahmen gearbeitet und versucht, z.B. unrealistisch steile Straßen zu vermeiden. Leider sind die Ergebnisse meiner Höhenberechnungen noch von sehr schlechter Qualität. Das ist nicht nur, aber besonders dort der Fall, wo es an einigen wenigen Objekten ele-Tags gibt.
Ich habe vor, diese Schwachstelle meiner Software gründlich anzugehen, aber wie ich gemerkt habe, ist das eine sehr komplexe Aufgabe. Womit du (ebenso wie die anderen betroffenen Nutzer meiner Software, du bist nicht allein mit dem Problem) aber hoffentlich schon bald rechnen kannst, womöglich in den nächsten Tagen: Die Möglichkeit, zwischen verschiedenen Verfahren zur Höhenberechnung zu wählen. Dabei werden dann auch einfachere, weniger fehlerträchtige Verfahren zur Wahl stehen. Teilweise sind solche alternativen Verfahren sogar schon in der Software enthalten - sie sind lediglich noch nicht auswählbar.
Moin,
ich habe folgende Frage zu OSM2WORLD:
Kann Osm2world 0.1.6 die OSM-Daten bereits so auswerten, das die darin enthaltenen 3D-Objekte auf den ebenfalls in der osm-Datei enthaltenen srtm-Daten dargestellt werden ? Kann es also die “tatsächliche Ansicht der Oberfläche” (srtm) mit den auf diese Oberfläche gesetzten 3D-Objekten zeigen ?
Alle meine bisherigen Versuche (am Beispiel Han. Münden: Weser in etwa 120m üNN und beidseiig "Berg"rücken mit 200m über Flußniveau; http://www.openstreetmap.org/?lat=51.4289546012878&lon=9.63754177093506&zoom=15)) zeigen zwar Gebäude, Straßen, Wege und Wasser. Nur leider nicht die Topologie in 3D; das Gitter des terrainViews bleibt eben, die Höhenlinien werden lagerichtig auf der so gebildeten Ebene(!) abgebildet.
Liegt das an den verwendeten Daten
- *.osm von josm 4177,
- srtm.osm von srtm2osm (mit -largeOption als v0.5)
- mit osmosis von v0.5 nach v0.6 konvertiert
- mit josm beide Dateien zu einer Ebene (Datei) zusammengeführt,
oder ist Osm2world noch nicht “soweit” ?
Aber auch mit den reinen srtm-Daten bleibt alles eben !???
Die Beispiele auf http://osm2world.org/screens/ lassen auch nicht sicher erkennen, ob das von mir erhoffte Ergebnis tatsächlich erzielbar ist.
aus http://wiki.openstreetmap.org/wiki/OSM2World:
“Elevation in OSM2World will be based on both information from OSM (mostly incline=* and ele=, as well as relative ordering of features using layer=, tunnel=* and bridge=*) and additional data sources for large-scale absolute elevation data, such as SRTM or OpenDEM data.”
Demnach sollte es doch klappen !!
auf Seite 1 dieses Threads steht:
“… Der Großteil des Programmcodes ist bereits auf die Verarbeitung von zusätzlichen Höhendaten neben den OSM-Daten ausgelegt, momentan werden dort als Eingabe eben noch durchgehend Nullwerte verwendet.”
Letzteres könnte das beobachtete Ergebnis erklären, würde es auch für die OSM-Daten gelten … Im Zitat geht’s aber um die “zusätzlichen Höhendaten neben den OSM-Daten”
Woran “klemmt’s” ??
Grüße aus Lübeck
Hallo projecter63,
wenn ein dargestelltes Objekt mit Tags wie ele ausgestattet ist, wird das von OSM2World 0.1.6 bereits berücksichtigt. Die Höhe von “unsichtbaren” Nodes und Ways, die lediglich auf den Verlauf des Terrains eine Auswirkung haben, wird in 0.1.6 allerdings noch nicht ausgelesen.
Für die Version 0.1.7, an der ich gerade arbeite, ist genau dieses Feature allerdings vorgesehen und (in meinem lokalen Entwicklungszweig) auch bereits implementiert. Die gute Nachricht ist also: Mit OSM2World 0.1.7 soll deine geplante Vorgehensweise prinzipiell funktionieren.
Leider ist die Qualität dabei bis jetzt noch weitaus schlechter, als ich ursprünglich gehofft hatte. Ich habe mir vorgenommen, dieses Problem durch die Entwicklung eines neuen Algorithmus für die verschiedenen Problemstellungen bei der Höhenberechnung von Grund auf zu lösen, aber dabei handelt es sich um ein längerfristiges Vorhaben. Auch wenn 0.1.7 also prinzipiell dreidimensionale Geländedarstellung bieten soll, wird erst eine deutlich spätere Version die wünschenswerte Qualität erzielen. Bis dahin wird man mit erkennbaren Fehlern im Resultat und langen Laufzeiten rechnen müssen. So viel als Warnung.
Wenn du magst, kannst du mir eine deiner .osm-Dateien auch mal vorbeischicken. Dann kann ich OSM2World während der Entwicklung auch hin und wieder damit testen.
Nach langer Wartezeit ist jetzt OSM2World 0.1.7 verfügbar. Neuigkeiten:
-
das Dateiformat .osm.pbf wird unterstützt
-
einige weitere Objekte werden dargestellt: Litfaßsäulen, Werbetafeln, Bänke, Handläufe an Treppen
-
beim Rendern von isometrischen Kacheln kann man außer von Süden auch von Norden, Osten oder Westen rendern
-
ein Bug bei der Berechnung der Breite dieser Kacheln wurde behoben
-
es werden sogenannte “parameter files” unterstützt, mit denen man mehrere Durchläufe gleichzeitig starten kann. Das verbessert die Performance, wenn man dieselbe Gegend aus unterschiedlichen Perspektiven rendern will.
-
man kann die zeitaufwendige Triangulierung des “leeren” Geländes abschalten
-
beim PNG-Export von der Kommandozeile poppten früher Fenster auf. Das wurde durch die Verwendung eines GLPbuffer behoben.
-
beim Export nach POVRay werden unechte Dreiecke jetzt gefiltert. Dadurch kommt es zu weniger POVRay-Fehlermeldungen und die Renderzeit wird etwas verkürzt.
-
im Viewer gibt es neue Menüeinträge zum Konfigurieren und Verlassen des Programms
Es gibt auch einige Änderungen, die speziell das hier zuletzt diskutierte Rendering mit echten Geländehöhen betreffen:
-
auch Höhenangaben an unsichtbaren Objekten (z.B. konvertierte SRTM-Daten) haben jetzt einen Einfluss aufs Gelände
-
der Höhenverlauf von langen Ways wird durch künstliche Nodes verbessert
-
und schlussendlich kann man die Höhenberechnung durch Verwendung des ZeroElevationCalculator kompett abschalten, wenn einem das Ergebnis die Rechenzeit nicht wert ist.
Bezüglich des Dauerproblems Höhenberechnung gibt’s eine gute und eine schlechte Nachricht. Die schlechte ist, dass die Qualität immer noch nicht wirklich vorzeigbar ist. Die gute ist, dass ich im Rahmen meiner Masterarbeit in den nächsten Monaten an Verfahren für die Verschneidung von Höhendaten und Straßennetzwerken arbeiten werde, die dann natürlich auch OSM2World zugute kommen sollen.
In den nächsten Wochen werde ich außerdem wieder an der Gebäudedarstellung basteln, die bei diesem Release etwas vernachlässigt wurde.
Hey super, freue mich schon von deiner Masterarbeit zu hören Vielleicht kannst du da ja mit den Leuten von OpenDEM zusammen arbeiten