Programmvorstellung: OSM2World

viw · 2011-11-10T20:08:32.000Z

Tordanik:

Hausdurchlässe (footway und tunnel) werden noch nicht umgesetzt

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.

dafür gibt es aber bereits Hauseingänge zu sehen. Wie groß hast du die eigentlich angenommen, da sie schon sehr sehr klein wirken.

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

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.

Tordanik:

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.

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?

Tordanik:

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.

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!

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.

marek_kleciak · 2011-11-11T07:05:57.000Z

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.

viw · 2011-11-11T07:20:05.000Z

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.

Tordanik · 2011-11-11T09:26:13.000Z

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.

viw:

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?

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.

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.

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.

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.

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.

viw · 2011-11-11T13:07:36.000Z

Tordanik:

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.

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.

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.

viw · 2011-11-11T16:17:06.000Z

Tordanik:

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

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

viw · 2011-11-11T16:42:42.000Z

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.

viw · 2011-11-11T17:07:06.000Z

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

marek_kleciak · 2011-11-11T22:23:06.000Z

Sehr gut, viw,
weiter so!

Grüße,
Marek

monotar · 2011-11-12T09:11:52.000Z

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)

viw · 2011-11-12T10:16:57.000Z

monotar:

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)

Aber gerne doch:
http://www.openstreetmap.org/?lat=51.089556&lon=13.710957&zoom=18&layers=M
Wie du leicht erkennen kannst gibt es mit komplizierteren Häusern noch kleinere Probleme. Dafür sind dann andere Dachtypen zu verwenden, welche aber noch nicht implemntiert sind.
Aber Achtung! Die 3dr Tags sind in OSM2world nur teilweise bis gar nicht implementiert. Wenn du dir als diese Dinge anschauen willst, musst du das 3D Plugin von Josm nutzen. Das wiederum stellt andere Dinge wie Bäume und Gleise noch nicht richtig oder gar nicht dar.

marek_kleciak · 2011-11-12T12:18:20.000Z

Hallo Monotar,
Du hast absolut Recht - die http://wiki.openstreetmap.org/wiki/DE:Roof_table ist unleserlich: zu Anfang habe ich diese Tabelle für Kendzi vorbereitet, damit er die Dachformen implementieren kann. Er bekamm von mir auch ein Scan auf dem alle Tags beschrieben sind.

Ich werde nächste Woche zu jeder Form eine umfassende Beschreibung liefern: Wenn danach Etwas unklar ist, bitte melden, ich besser es nach. Zum Glück habe ich jetzt eine absolut geniale Hilfe beim Anlegen der Wiki seiten - ein OSM Freund, DINENISO hat die Arbeit sehr beschleunigt!

Was die Implementierung und Tagging angeht: mein und Kendzis größtes Problem war die Frage: machen wit Tagging so, dass sehr schnell intuitiv verstanden wird was gemeint ist (Flachdach, Schrägdach etc.) oder benutzen wir eine nummerische Form.

Ich bevorzuge eigentlich stets die menschennahe Beschreibung weil die andere so zeimlich kriptisch und unbeliebt ist, und obwohl ich die Formen selbst zusammen getragen habe, weiß ich jetzt aus dem Gedächnis nicht was sich z.B. hinter der Form 3.3 verbirgt. Leider gibt es bei den Dächer eine derartige Formenvielfalt dass wir mit Kendzi keine bessere Lösung gesehen haben.

Ich denke, dass früher oder später viele 3D Programme beide Beschreibungen verstehen werden und ob 0.0 oder Flachdach als Tagging die Geometrie richtig darstellen werden. Auch muß einem klar sein, dass die Implementierung der einzelnen Dachformen eine gewisse Zeit braucht.
Wenn ich also mit DINENISO Hilfe alles ordentlich beschrieben habe, kann man - wenn man will - auf Vorrat taggen, wohlwissend dass die Implementierung folgt.

SunCobalt · 2011-11-12T12:40:15.000Z

ich finde das building:roof:shape=3dr recht sinnlos. Wenn ein Tag wie 3dr:type=2.0 angegeben wird, ist das Schema doch eigentlich klar

Tordanik · 2011-11-15T01:09:42.000Z

Tordanik:

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

Ist jetzt erledigt. Wer neue Features wie diese immer sofort ausprobieren möchte, kann übrigens zur latest-Version greifen:

http://osm2world.org/download/files/latest/

Die Kameraposition wird nach dem Reload nur sinnvoll sein, wenn sich die Bounding Box der Objekte in der geladenen Datei durch die Bearbeitungen nicht geändert hat.

viw:

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

Als Tag für den Freiraum über einem Objekt wird derzeit maxheight:physical verstanden, das Tag kommt daher auch bei der Berechnung von Gebäudedurchgängen zur Anwendung.

Ich vermute aufgrund deiner neuerlichen Bearbeitungen, dass du mit height gearbeitet hast? Bei Gebäudedurchgängen spielt das Tag für OSM2World keine Rolle. Die Verwendung von height für die lichte Höhe über einem Weg ist mir eigentlich auch nicht als etabliertes Tagging bekannt.

monotar:

Ich würde auch gerne mal paar Häuser in 3D mappen, nur leider sehe ich bei der Seite überhaupt nicht durch.

Da wir hier im OSM2World-Thread sind und OSM2World derzeit nur roof:shape-Tags auswertet, wäre die Erklärung für Dächer eigentlich:

roof:shape = <Wert aus dieser Übersicht>

roof:height = <Höhe in Metern> (Dachhöhe, optional)
roof:ridge:direction = <vgl. direction-Proposal> (Firstrichtung, optional wenn First längs)

Darauf, dass sich das alles auch schnell ändern kann, habe ich ja schon hingewiesen.

SunCobalt · 2011-11-15T06:36:32.000Z

Tordanik:

roof:ridge:direction = <vgl. direction-Proposal> (Firstrichtung, optional wenn First längs)

Darauf, dass sich das alles auch schnell ändern kann, habe ich ja schon hingewiesen.

Kannst Du mit Kendzi sprechen? Er hat das mMn besser gelöst. (3dr:direction=begin|end). Es wäre besser, wenn die ersten beiden Renderer die Dächer unterstützen nicht unterschiedliche Tags benötigen. Bei den sprechenden Tags für die Dachform hatte Kendzi ja angeboten, die sprechenden Namen zu implementieren. Seine Liste diesbezüglich werde ich heute Abend mal ausfüllen.
Wäre es möglich, auch 8.0.1 und 6.4. sowie schräge Flachdächer zu unterstützen? Eine Kirche als markanter Punkt würde mMn den Wiedererkennungswert einer Gegend deutlich erhöhen.

Tordanik · 2011-12-11T22:32:59.000Z

SunCobalt:

Kannst Du mit Kendzi sprechen? Er hat das mMn besser gelöst. (3dr:direction=begin|end). Es wäre besser, wenn die ersten beiden Renderer die Dächer unterstützen nicht unterschiedliche Tags benötigen.

Um euch über den aktuellen Stand nicht ganz im Unklaren zu lassen: Ich bin seit einigen Wochen mit Kendzi im Gespräch. Vielleicht wird es sogar möglich sein, dass wir Teile unserer Programme zusammenlegen und den Dächer-Code gemeinsam weiterentwickeln. Momentan hängt es aber vor allem an technischen Fragen und Inkompatibilitäten - da muss ich einfach mal die Zeit finden, mich länger dranzusetzen.

Beim Tagging werden wir hoffentlich gemeinsame Lösungen finden. Da hoffe ich, dass ich spätestens nach dem 3D-Workshop in Garching ein klareres Bild habe.

_i · 2011-12-12T05:49:11.000Z

Ich überlege ob ich dich bei dem COLLADA Export unterstützte. Wir bräuchten dass eh später für einen Import für Open3DMap und dann können andere die Daten vielleicht auch besser nutzen

marek_kleciak · 2011-12-12T07:51:31.000Z

Hallo Tordanik, Kendzi ,!i!

ich finde es super dass ihr nach gemeinsamen Wegen sucht, fantastisch!

Die Jungs aus Lodz können Kendzi mit dem Auto mitnehmen, also kommt er wohl auch nach Garching. Ich freue mich schon auf den Workshop!

Tordanik · 2011-12-13T03:22:20.000Z

!i!:

Ich überlege ob ich dich bei dem COLLADA Export unterstützte. Wir bräuchten dass eh später für einen Import für Open3DMap und dann können andere die Daten vielleicht auch besser nutzen

COLLADA-Unterstützung wäre sehr willkommen.

Wenn du dich drum kümmern magst, schreib mich doch am besten mal an! Meine Adresse kennst du ja.

_i · 2011-12-13T06:33:58.000Z

Logo, denn dein Programm ist mir mitlerweile doch ein wenig groß geworden um da spontan durchzusehen. Vor Feb wird das aber def. nichts