Programmvorstellung: OSM2World

Communities Deutschland (Germany)
,
41

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.

42

Sehr gut Tordanik,
weiter so!

Viele Grüße,
Marek

43

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

44

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

45

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 :wink: 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 :slight_smile:

46

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.

47

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

48

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?

49

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

50

Der Vorschlag mit dem Status der Implementierung kam von Dir :slight_smile: 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…

51

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.

52

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.

53

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.

54

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. :wink:

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.

55

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.

56

Bitte auch gleich die Höhen mit angehen. Hier werden offenbar auch nur die Hälfte angenommen. Jedenfalls im Vergleich zur Gebäudehöhe.

57

Ein weiterer Fehler scheint die Auswertung von Multipolygonen zu sein. Hier wird die Höhe der Relation nicht berücksichtigt, wohl aber jene des Umrisses. Auch wenn sonst am Umriss keine weiteren Tags hängen.

58

Hier mal ein kleiner Vorgeschmack auf die Möglichkeiten:
http://wiki.openstreetmap.org/wiki/File:OSM3Dworshop_Prohlis_3D.png

59

Sehr gut, viw,
weiter so!

Grüße,
Marek

60

Ich würde auch gerne mal paar Häuser in 3D mappen, nur leider sehe ich bei der Seite überhaupt nicht durch. Kann mir mal jemand einen Link zu einfach gemappten Häusern schicken, also mit einfacher Dachform aka normales Schrägdach mit spezifischer Höhe oder sowas. Bei dem Wikivorschlag http://wiki.openstreetmap.org/wiki/DE:Roof_table seh ich ich nur böhmische Dörfer, mir ist nichtmal klar, woran letztendlich welcher Tag muss (H1, L1, H2, alles klar, ne???; Typ 2.0 brauch ich erstmal)