Leser der dev-Mailingliste und Besucher der FOSSGIS kennen es vielleicht schon: Es handelt sich um ein in Java geschriebenes Open-Source-Werkzeug, mit dem man dreidimensionale Modelle auf Basis von OSM-Datenausschnitten erstellen kann. OSM2World funktioniert auf gängigen Systemen wie Windows, Linux und Mac; es kann über eine grafische Oberfläche oder ein Kommandozeileninterface bedient werden.
Wer jetzt noch keine Idee hat, was er damit anstellen könnte:
Kartenkacheln für eine “isometrische” Stadtansicht erstellen
Eine 3D-Grafik der frisch gemappten Gebäude produzieren und damit z.B. den eigenen Desktop schmücken (oder Werbung für OSM machen ;))
Modelle als Ausgangspunkt eines eigenen Projekts mit Blender, POVRay o.a. herstellen
Szenen für interaktive Anwendungen, Spiele oder dergleichen generieren
OSM2World als Bibliothek in eigene Anwendungen einbauen oder neue Exportformate ergänzen
Es ist nicht schwerer einzurichten als andere typische Java-Software wie JOSM - Windows-Installer oder ähnliche Hilfen gibt es bisher allerdings nicht. Bei wem es nicht auf Anhieb klappt: Ich helfe gern. Mehr Info gibt’s auch im OSM-Wiki (englisch).
Das Programm ist in einem ziemlich frühen Entwicklungsstadium und noch lange nicht so stabil und schnell, wie es sein sollte. Aber: Wenn jemandem noch ein bestimmtes Feature fehlt / das Programm für einen bestimmten Zweck zu langsam ist / ein Objekt nicht gerendert wird / etwas nicht funktioniert … jederzeit bei mir melden! Ich habe mich auch bisher bei der Entwicklung schon an konkreten Wünschen von Nutzern orientiert und werde das weiterhin so halten.
Ach, und wenn jemand mit Texturen, Modellen, Code, beim regelmäßigen Installer-Basteln oder mit eigenen Ideen helfen will: Gerne!
Ja, vielleicht nett, aber rein deutschsprachig bremst die internationale Zusammenarbeit und Weiterentwicklung.
Wenn, dann mehrsprachig. Aber ich bei derartigen Projekten liegt der Schwerpunkt meist zuerst auf dem Inhalt und weniger auf der Mehrsprachigkeit…
Aber zurück zum eigentlichen Thema: schaut super aus, dieses Tool!!
Du kannst theoretisch das .jar direkt starten, aber die OpenGL-Anbindung (die für die grafische Oberfläche nötig ist) funktioniert dann nur mit zusätzlichen Pfadangaben auf der Kommandozeile. Aus dem Grund habe ich .bat-Dateien für die gängigen Systeme beigelegt. In deinem Fall sollte eigentlich die “osm2world-windows-amd64.bat” funktionieren.
Hm … ich erkenne den Fehler, aber ich bin mir nicht sicher, wieso er bei dir auftritt. Was ist das für eine Datei - direkt vom Server oder mit irgendeinem Programm bearbeitet? Kannst du mir die Datei vielleicht mal schicken? (-> http://osm2world.org/contact/)
Vorgesehen ist es. 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. Was fehlt ist im Wesentlichen das eigentliche Einlesen echter Daten. Ich habe mich allerdings noch nicht entschieden, welches Format und welche Datenquelle ich verwenden möchte, und habe mit dem Thema DEM auch keine Erfahrung.
Den Fehler erhalte ich auch wenn ich die gepackte OSM laden will (ich glaub Endung gz).
Ungepackt läd es die Datei.
Allerdings rödelt der ewig rum - hab nach 1h abgebrochen - bei einer 1,8 MB großem OSM.
Fortschrittsbalken bei Schritt 1/5 stehen geblieben - gestartet über “osm2world-windows-amd64.bat”.
Allgemein mal folgende Information: OSM2World kann .osm-Dateien und gezippte OSM-Dateien dann lesen, wenn sie mit Osmosis geladen werden können - ganz einfach deshalb, weil es intern Osmosis verwendet. Außerdem können noch .osm-Dateien mit lokalen Änderungen durch JOSM (die von Osmosis normalerweise nicht verstanden werden) gelesen werden. Letzteres geht allerdings nur mit unkomprimierten .osm-Dateien.
Bei einer späteren Phase als 1/5 wären die Performanceprobleme, die mein Programm noch hat, als Ursache in Frage gekommen; dann hätte ich höchstens empfehlen können, durch Bearbeiten des Startskripts in einem Texteditor zusätzlichen Arbeitsspeicher zuzuweisen. Die erste Phase geht aber normalerweise sehr schnell, so dass hier eine andere Ursache vorliegen muss.
Daher auch hier wieder die Bitte, mir doch die Datei vorbeizuschicken.
Ich hab auch damit experimentiert, die Liste der verwendeten Tags automatisch erstellen zu lassen: http://osm2world.org/docs/taglist.txt Die Keys müssten komplett sein, die Tags sind es aber aus technischen Gründen nicht mal annähernd.
Bei vielen noch nicht dargestellten Objekten fehlt übrigens einfach nur das Hinzufügen. Wer also Wünsche hat, einfach mal äußern. Es sei allerdings angemerkt, dass die Standard-Konfiguration von OSM2World ausschließlich physische Gegebenheiten abbildet.
Jetzt noch mal ein komplett anderes Thema: Technische Probleme.
64-Bit-Probleme unter Windows
Die korrekte Datei zum Starten auf Windows-Installationen mit 64 Bit ist osm2world-windows-amd64.bat - egal, ob der Prozessor von AMD ist oder nicht.
Edit: Laut Rückmeldungen im Rest dieses Threads kommt es zu dem Problem auch, wenn 32-Bit-Java installiert ist, und lässt sich durch Installation von Java mit 64 Bit (über den IE64) beheben.
Wenn es trotzdem zu Meldungen wie “Can’t load IA 32-bit .dll on a AMD 64-bit platform” kommt, verstehe ich den Fehler nicht. Laut Internetrecherchen kann es anscheinend, warum auch immer, passieren, dass ein 64-Bit-Java Probleme mit dem Laden von nativem Code hat. OSM2World braucht für den interaktiven Betrieb zwingend native OpenGL-Bibliotheken (auf der Konsole dagegen nur für den PNG-Export). Man kann es dann höchstens einmal damit versuchen, ein 32-Bit-Java zu installieren. Andere Ideen habe ich gerade nicht.
“Fortschrittsbalken bleibt bei 1/5 stehen”
Bei einem solchen Fall hat sich inzwischen herausgestellt, dass beim Ausschneiden einer Bounding Box mit Osmosis unvollständige Flächen entstanden waren, wodurch der Ladevorgang abgestürzt ist - leider ohne offensichtliche Fehlermeldung. Osmosis muss hier mit dem Parameter completeWays=yes verwendet werden. Das Problem kann leider auch auftreten, wenn man zwar selber den Parameter verwendet, aber eine Datei mit Daten z.B. für ein Bundesland heruntergeladen hat, die ohne ihn erstellt wurde.
@quasilotte: Kann es sein, dass bei dir eine ähnliche Situation vorliegt? Womit hast du die Eingabedatei ursprünglich erstellt?
Wie lange dauert das Laden einer 2,4 MB *.osm Datei aus JOSM gespeichert? Bei mir hing der Ladebalken bei 4/5 und ich habe nach einer halben Stunde abgebrochen. Dauert das so lange, oder hängt das Script dann? Werde morgen wenn ich mal mehr Zeit habe mal kleinere Ausschnitte versuchen.
Das kann ich zwar ergänzen. Allerdings ist das Tag nur wirklich sinnvoll im Zusammenhang mit einer Möglichkeit, Gebäudeteile taggen zu können, und ich bin von der bisherigen “Lösung”, Gebäudeteile als Gebäude (building=yes) einzutragen, wenig begeistert.
Stockwerke sind nämlich keine absolute Höhenangabe, wie viel Platz brauchen also diese x nicht existierenden Stockwerke unter dem building:min_level? Normalerweise würde das einfach der Höhe der entsprechenden Stockwerke in denjenigen Gebäudeteilen des Gebäudes, wo sie tatsächlich existieren, entsprechen. Aber dazu bräuchte man eben die Unterscheidung zwischen dem Gesamtgebäude und den Gebäudeteilen…
Wenn also das hübsche Beispielgebäude für building:min_level z.B. am Hang steht (und der Boden ist fast nie perfekt flach) schließen die Dächer der Teile nicht mehr wie vorgesehen bündig ab, und die Fensterreihen der Stockwerke sind ebenfalls nicht auf gleichem Niveau. Dieses konzeptionelle Problem fällt natürlich bei Programmen, die keine Bodenerhebungen berücksichtigen - und das sind die meisten - nicht auf.
Schritt 4/5 ist die Berechnung des Terrains. Die Dauer hängt da kaum von der Menge der Daten, sondern von der Größe der Bounding Box um die Daten ab. Wenn in den Daten ein paar Stromleitungs- oder Fluss-Ways mit zig Kilometern Länge drin stecken, kann das die Fläche schon ziemlich aufblähen. 4/5 und 5/5 sind aber auch im Normalfall mit Abstand die längsten Phasen.
Wie schon erwähnt: Etwas Extra-RAM im Startskript zu spendieren schadet meist auch nicht.
