Programmvorstellung: OSM2World

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

Und wieder einmal eine neue Version: OSM2World 0.1.8 ist verfügbar.

Neue Features:

• Die Höhenberechnung ist jetzt standardmäßig deaktiviert.

• In der grafischen Oberfläche gibt es einen Statistik-Dialog, einen Menüeintrag zum erneuten Laden der aktuellen Datei und einige weitere Detailverbesserungen.

• Der OBJ-Export kann in mehrere Dateien aufgeteilt werden, da speziell Blender Probleme beim Laden zu großer OBJ-Szenen hat.

• Der POV-Export lagert die Definitionen von Materialien und Objekten sauber in Definitionen aus, so dass sich die Optik des Render-Ergebnisses leichter anpassen lässt.

• Der PNG-Export erlaubt die Konfiguration der Hintergrundfarbe.

• Bei der orthographischen Darstellung wurden Grafikfehler auf Systemen mit niedrig aufgelöstem z-Buffer behoben. Insbesondere ist damit das Rendering auf Servern ohne Grafikkarte und Monitor problemlos möglich.

• Verschiedene Bugs wurden beseitigt.

Diese Version enthält auch meine ersten Experimente mit 3D-Gebäudeattributierung (vgl. den Thread 3D Dächer mit Gauben), d.h. Unterstützung für roof:ridge/edge/apex=yes-Geometrie, roof:shape-Tags sowie als building:part=* markierte Gebäudeteile. Da sich das Tagging hier allerdings noch sehr im Fluss befindet, ist das eher für Mapper interessant, die kein fertiges Datenmodell erwarten, sondern sich mit eigenen Erfahrungen an der Entwicklung des 3D-Taggings beteiligen möchten.

Sehr gut Tordanik,
weiter so!

Viele Grüße,
Marek

Hey das mit den Attributen sieht schon echt toll aus. Vielen Dank an der Stelle einfach mal, dass ihr das so durchzieht

Es werden wieterhin fleißige Hände für dei Implementierung weiterer 3D Objekte gesucht. Mit der Zeit sollte eine Library entstehen, aus der man Objekte nimmt und komplexere Szenen zusammen bauen kann. Ich habe auch zum Glück ein Hilfsangebot für das Zusammentragen der Elemente in der Wiki bekommen. Im Grunde werden das Tickets die man nach und nach implementiert.

Ich warte schon auf Deine (!i!) 3D Symbole!

Besonders gut an Tordaniks Arbeit finde ich Export in obj - es wird durch sehr viele 3D User verwendet. Wir sollten uns an 3D Forem wenden und diese über OSM und die OBJ Export informieren!

Grüße,
Marek

ich würds auch gern machen Marek, aber wie gesagt, mir fehlt die Zeit. Sehen wir es mal so, Rom wurde auch nicht an einem Tag erbaut. Auch bei OSM nicht Habe für die FOSSGIS nen Lightning Talk angemeldet, hoffe nächstes Jahr sieht es besser aus.

Wir haben hier schon mal hingewiesen:
http://www.blendpolis.de/viewtopic.php?f=25&t=33201
Man muss bei sowas natürlich ein wenig aufpassen, sonst werden Erwartungen geweckt, die man so schnell nicht erfüllen kann. Das wird schon noch

Die neue Version ist Klasse geworden. Mit den Dächern weiß ich zwar immer noch nicht welches der bessere ist, aber dort müssen wir unbedingt das Tagging angehen, damit nicht Arbeit umsonst geleistet wird.
Hausdurchlässe (footway und tunnel) werden noch nicht umgesetzt, dafür gibt es aber bereits Hauseingänge zu sehen. Wie groß hast du die eigentlich angenommen, da sie schon sehr sehr klein wirken.

Ein Problem hat das Programm offenbar, wenn man den Computer herunterfahren möchte (powerknopf drücken) ohne das Programm beendet zu haben. Nach diesem Versuch ist das Programm zwar noch offen, aber nicht mehr ansprechbar.

Ich habe schon gesehen, dass man auch tiles rendern kann. Sind das dann die gleichen wie bei Mapnik für Openlayers? kann man die vielleicht auch über die Manikkarte legen? Immerhin fehlen ja hier alle Namen und sonstigen Informationen.

Durchgänge (Tunnel) sind auch nicht ganz ohne ,o)

Macht man alles richtig, dann kann man mit zwei Wegen getaggt als Tunnel in einem Gebäude auch ein Kreuzgewölbe erzeugen: siehe : http://wiki.openstreetmap.org/wiki/DE:3D_building#Durchfahrt_.28Tunnel.29

Die neuen Tabellen sind Klasse. Dort kann man sofort ablesen ob die Dinge schon sichtbar sind. Werden eigentlich bei allen Objekten die Ausdehnung abgefragt? Also insbesondere Wegbreiten etc. Werden Fußwege an Straßen unterstütz? Oder ist es hier besser gleich Flächen zu erfassen?

Stimmt schon, mir würde es auch gefallen, wenn man sich da allmählich etwas stärker angleicht.

Doch, werden sie. Allerdings nur bei Tagging mit covered=yes. Bei tunnel=yes gehe ich von einem Tunnel unter dem Haus aus (was keinen sinnvollen Effekt hat, wenn die Höhenberechnung abgeschaltet ist). Ich weiß, dass die beiden Fälle in der Praxis gerne unterschiedslos mit tunnel=yes getaggt werden, aber irgendwie muss ich sie nun mal ohne allzuviel Raten auseinander halten können.

Der Standardwert in OSM2World ist 2m hoch, 1m breit. Die Tags width und height werden, falls vorhanden, berücksichtigt.

width-Tags sollten bei vielen linienförmigen Objekten schon unterstützt werden, bei allen highways ist das der Fall. area:highway wird bisher nicht unterstützt, obwohl ich es mir längerfristig sehr gut vorstellen könnte.

Fahrspuren, Fuß- und Radwege werden bisher überhaupt nicht nicht dargestellt. Ich warte da auch ein wenig ab, ob sich nicht doch einmal Fortschritte beim Datenmodell abzeichnen und wir das Thema Linienbündel endlich sauber lösen. Selber will ich neben den Gebäudeattributen nämlich nicht gleich noch ein weiteres Thema mit größtenteils ungeklärtem Tagging anschneiden.

Generell wäre es mir aber auch durchaus recht, wenn jemand einen bestimmten Themenbereich in OSM2World “adoptieren” und verstärkt ausbauen möchte. Wenn ich mich allein um das Gesamtprogramm kümmere, dann kann ich jedes Thema eben nur recht oberflächlich behandeln. Jemand, der sich z.B. speziell auf Eisenbahn-Infrastruktur, auf Hochspannungsleitungen oder was auch immer konzentriert, könnte sicher viel schneller einen hohen Detailgrad in der Darstellung der jeweiligen Objekte erreichen.

Die Konventionen hinsichtlich Kachelnummern, Zoomstufen etc. sind identisch zu denen, die bei Mapnik, Openlayers und im Rest der OSM-Rendering-Welt üblich sind.

Ein Problem bei der Kombination mit anderen Kachelquellen ist allerdings das Seitenverhältnis der Kacheln. Wir haben hier in Passau schon viel mit solchen OSM2World-Tiles experimentiert und sehr schöne Ergebnisse mit “isometrischem” Rendering bekommen. Allerdings erhält man bei dieser Art der Darstellung Kacheln, die weniger hoch als breit sind, wodurch sie sich nicht mit den üblicherweise verfügbaren quadratischen Kacheln kombinieren lassen. Beschriftungs-Layer o.ä. müsste man dann extra für diesen Zweck noch einmal in einem passenden Seitenverhältnis rendern.
Wenn man vor allem auf die Kombinierbarkeit mit quadratischen Kacheln Wert legt, könnte man auch entweder eine Ansicht senkrecht von oben rendern oder bei Schrägansicht eine Verzerrung in Kauf nehmen. OSM2World selbst setzt da keine Grenzen.

Übrigens: Wir würden durchaus gerne die Ergebnisse unserer Experimente auch einmal der allgemeinen Öffentlichkeit zur Verfügung zu stellen - d.h. eine OSM2World-Slippymap aufsetzen. Momentan basteln wir aber noch an der Serversoftware und der Darstellung, weil wir alle keine Erfahrung mit dem Aufsetzen eines Tileservers haben und die Anforderungen bei 3D-Kacheln obendrein etwas ungewöhnlich sind. Wenn sich jemand mit JS/OpenLayers auskennt, ist er herzlich eingeladen, mitzumachen!

Edit: Tippfehler

Der Vorschlag mit dem Status der Implementierung kam von Dir und ich finde auch das das ein guter Vorschlag ist… Was Wege angeht, sollen Flächen Vorrang von einer Breite haben. Sprich: Ist ein Weg als Fläche erfaßt (bevorzugt, da besser die räumliche Situation widerspigelt), wird die Breite eines Weges die an die Straßenmittelachse angehängt ist, nicht berücksichtigt.

Ich bin so ziemlich Radikal was die Erfassung der Fußwege angeht: ich bin der Meinung, man sollte sie auch als Flächen erfassen, wei dadurch die 3D Darstellung wesentlich besser sein kann. Wahrscheinlich wird die Mehrheit momentan anderer Meinung sein, weil ein Vergleichsmodell fehlt. Das kommt noch aber…

Hier ist aber noch ein kleiner Bug in der Version 0.1.8
Hausdurchbrüche werden nur auf einer Seite des Weges dargestellt. Die zweite Hälfte fällt unter den Tisch. Die Höhe ist nur schwer nachmeßbar, solange keine Geschosse eingeszeichnet sind.

Welche Vorraussetzungen müssen denn gegeben sein, um so einen Bereich zu adoptieren? Wie weit muss man dafür in die Programmierung eindringen? Oder soll man nur irgendwelche Parameter für Objekte liefern?

Also ich habe einen renderingserver für Mapnik mithilfe des fertigen Paketes von amm gebaut und der läuft auch recht zuverlässig. Außerdem wird dort noch der Stil der openptmap gerendert und bei Bedarf mit angezeigt.
Inwiefern sich mod_tile jetzt anpassen lässt um statt Mapnik mit dem Rendering zu beauftragen dann eben osm2world angefragt wird ist fraglich.
Im Zweifelsfall könnte man aber auch die Datei umbenennen. Wichtig ist nur, dass das Programm dann mit den übergebenen Parametern wunschgemäß reagiert.
Was den Beschriftungslyer angeht, so wäre es wahrscheinlich sinnvoller, diese Beschriftung in den 3D Layer zu integrieren. Dann könnte man Hausnummern neben dem Eingang darstellen und Werbeschilder für den Sußermarkt oder Bäcker an die Hauswand malen.

Doch, werden sie. Allerdings nur bei Tagging mit covered=yes. Bei tunnel=yes gehe ich von einem Tunnel unter dem Haus aus (was keinen sinnvollen Effekt hat, wenn die Höhenberechnung abgeschaltet ist). Ich weiß, dass die beiden Fälle in der Praxis gerne unterschiedslos mit tunnel=yes getaggt werden, aber irgendwie muss ich sie nun mal ohne allzuviel Raten auseinander halten können.

Die Idee ist schon nicht schlecht, zwischen einem Tunnel in einem Gebäude und dem Tunnel im Gelände unter dem Gebäude zu differenzieren. Wenn ich allerdings betrachte wie die Menschen Taggen, dann ist die Mehrheit erdgeschossig gelegener Durchgänge als “Tunnel” markiert.

Wir haben uns in Garching beim letzten Meeting auf ein Schema: http://wiki.openstreetmap.org/wiki/DE:3D_building#Durchfahrt_.28Tunnel.29 geeinigt.

Praktisch bedeutet es: Damit ein Weg mit Tunnel:yes als eine erdgeschossige Durchfahrt von einem Gebäude erkannt wird, müssen seine Anfang- und Endpunkt auf dem Gebäudeumriß liegen.

Da wir in OSM-4D eine Lösung mit Höhenangaben anstreben, wird man sowieso dank dieser Angabe wissen, wie die Lage von dem tunnel ist.

Die Reloadfunktion ist schon ganz nett. Aber leider ist es noch sehr umständlich wenn man bestimmte Details beobachten möchte, da nach einem Reload die Kameraposition verloren geht. Wenn du diese vor dem Reload noch speichern könntest und danach wiederherstellen könntest, wäre das echt Klasse.

Das Thema Tagging von Hausdurchgängen habe ich wegen des anscheinend größeren Diskussionsbedarfs jetzt mal in einen eigenen Thread ausgelagert.

Die Probleme mit “halben” Durchgangsöffnungen und den Verlust der Kameraposition beim Reload kann ich nachvollziehen. Beides werde ich demnächst beheben.

Ohne Änderungen am Java-Code kann man leider keine neuen Objektarten einbauen - Programmierkenntnisse wären also ideal, dann kann man eigenständig arbeiten. Wenn sich aber jemand z.B. mit 3D-Modellierung auskennt, dann könnte ich mit Modellen für bestimmte Dinge auch schon sehr viel anfangen.

“Besser als nichts” wäre zumindest eine Sammlung der relevanten Tags in einem Themenbereich, die sich auf die Darstellung auswirken sollen, samt ggf. einer informellen Beschreibung, wie es aussehen soll: Dann bin ich zwar doch derjenige, der es letztlich einbaut (und kann nicht garantieren, wann ich dazu komme), aber es erleichtert mir zumindest die Arbeit bei Themen, mit denen ich mich beim Mapping selber weniger beschäftige. In so einem Fall wäre es mir lieb, wenn es nur um eher unkontroverse Tags ginge.

Falls es konkretes Interesse an einem Themenbereich gibt, am besten mal direkt bei mir melden.

Verglichen mit einem “normalen” Setup gibt es noch einige zusätzliche Stolpersteine. Insbesondere ist das 3D-Rendering zu langsam, um die Kacheln erst beim Zugriff darauf zu berechnen. Das heißt, dass zumindest ein Teil der Berechnungen wohl auf Vorrat erfolgen muss - was natürlich letztlich unnötigen Rechenzeit- und Speicherplatzverbrauch bedeutet.

Auch mit OpenLayers stoßen wir auf ein paar Spezialprobleme: Beispielsweise ist es uns nicht gelungen, bei nicht quadratischen Kacheln noch korrekte lat/lon-Werte zu bekommen. Und ein besonders interessantes Feature wäre natürlich eine “Rotationsfunktion”, um die Karte aus unterschiedlichen Himmelsrichtungen betrachten zu können. Die Kacheln könnten wir wahrscheinlich produzieren, nur eine JavaScript-Oberfläche dafür existiert noch nicht.

Die Möglichkeit, Text in die 3D-Darstellung einzubauen, wäre sicher ein Gewinn, aber natürlich wieder mit viel Programmierarbeit verbunden.

Es ist auch ein bisschen ein anderer Einsatzzweck: Ja, der Name der Stadt auf dem Ortsschild ist nett, aber man will ihn beim Reinzoomen vielleicht trotzdem noch ganz unrealistisch über den Dächern schweben haben.

Ich bin mir nicht ganz sicher, was dein Programm letzendlich macht. Aber bei mir schreitet der Balken recht schnell voran. am längsten hält er sich bei der Generierung der Öberfläche auf. So dass ich sagen würde er kann schnell auch ein paar Kacheln rechnen.
Was die Unterschiedlichen Richtungen angeht, so wären wieder zwei Schritte möglich. Erstens aus allen vier Himmelsrichtungen je ein Layer. Oder aber das Rendering direkt auf dem Clientrechner. Dann wäre aber der Ansatz von Cartagen.org sicher der bessere.