Programmvorstellung: OSM2World

viw · 2011-11-10 21:08:32

Tordanik wrote:

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 wrote:

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 wrote:

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-11 08:05:57

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:3 … 8Tunnel.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-11 08:20:05

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-11 10:26:13

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 wrote:

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-11 14:07:36

Tordanik wrote:

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-11 17:17:06

Tordanik wrote:

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-11 17:42:42

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-11 18:07:06

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

marek kleciak · 2011-11-11 23:23:06

Sehr gut, viw,
weiter so!

Grüße,
Marek

monotar · 2011-11-12 10:11:52

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-12 11:16:57

monotar wrote:

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.08 … 8&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.

Last edited by viw (2011-11-12 11:23:56)

marek kleciak · 2011-11-12 13:18:20

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-12 13:40:15

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-15 02:09:42

Tordanik wrote:

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 wrote:

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 wrote:

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-15 07:36:32

Tordanik wrote:

+ 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.

Last edited by SunCobalt (2011-11-15 11:04:53)

Tordanik · 2011-12-11 23:32:59

SunCobalt wrote:

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-12 06:49:11

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

Last edited by !i! (2011-12-12 09:24:41)

marek kleciak · 2011-12-12 08:51:31

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-13 04:22:20

!i! wrote:

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-13 07:33:58

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

SunCobalt · 2012-03-25 13:30:06

ist vielleicht besser hier aufgehoben

2 unterschiedliche Fehler bekomme ich bei unterschiedlichen Gebieten:

Exception in thread "main" org.osm2world.core.math.InvalidGeometryException: outer polygon is not simple for this object: 1443708
        at org.osm2world.core.map_data.data.MapArea.getPolygon(Unknown Source)
        at org.osm2world.core.map_data.data.MapArea.getAreaSegments(Unknown Source)
        at org.osm2world.core.map_data.data.MapNode.calculateAdjacentAreaSegments(Unknown Source)
        at org.osm2world.core.map_data.creation.OSMToMapDataConverter.createGridElements(Unknown Source)
        at org.osm2world.core.map_data.creation.OSMToMapDataConverter.createMapData(Unknown Source)
        at org.osm2world.core.ConversionFacade.createRepresentations(Unknown Source)
        at org.osm2world.core.ConversionFacade.createRepresentations(Unknown Source)
        at org.osm2world.console.Output.output(Unknown Source)
        at org.osm2world.console.OSM2World.executeArgumentsGroup(Unknown Source)
        at org.osm2world.console.OSM2World.main(Unknown Source)
Caused by: org.osm2world.core.math.InvalidGeometryException: polygon must not be self-intersecting
Polygon vertices: [(26775.427000000036,7785.868936466224), (25804.233000000033,7719.693915860605), (25360.433000000172,7668.517980935729), (25291.749000000047,7664.195504410919), (25162.452000000107,7661.262402070345), (24904.733000000015,8011.1234238597735), (24916.68899999997,8125.147452494471), (24910.123000000083,8128.610883371938), (24909.69600000007,8127.7836300432145), (24846.829000000027,8096.414521969507), (24767.792000000027,7992.881262152751), (24748.96900000015,8004.770626771697), (24724.118999999973,8036.8878190471505), (24706.57000000006,8059.55335075152), (24674.236999999976,8105.811949410457), (24690.091999999986,8162.638968517096), (24705.884000000005,8233.808172152038), (24947.265000000167,8199.745360845114), (24925.31300000003,8157.70843275204), (25005.16900000015,8114.448369659245), (25191.97799999997,8207.356477808607), (25149.69800000003,8162.186726300037), (25161.92700000019,8105.7457701375915), (25291.301000000032,7889.476381491875), (25388.832000000042,7990.179146835398), (25396.049000000075,7999.399445860451), (25506.187000000187,8139.872604359552), (25528.55900000001,8117.007318577606), (25575.7040000001,8067.626994865258), (25575.725000000097,8067.6049356689955), (25586.148000000045,8056.685673384955), (25692.772000000125,7950.122229531409), (25801.734000000175,7835.118826654353), (25944.212000000207,7943.648371835817), (25946.053000000084,7956.397596533437), (27325.025000000023,8098.002815421638), (27288.324000000124,8124.276081023766), (27210.17600000007,8055.39522035307), (27051.311000000027,7987.609384487776), (26978.11900000019,8058.5496630513235), (26976.957000000042,8056.718761938386), (26906.201000000074,7945.412964054021), (26750.33900000006,7844.44847167606), (26759.1100000001,7823.969643807447), (26775.427000000036,7785.868936466224)]
        at org.osm2world.core.math.SimplePolygonXZ.assertNotSelfIntersecting(Unknown Source)
        at org.osm2world.core.math.SimplePolygonXZ.<init>(Unknown Source)
        at org.osm2world.core.map_data.data.MapArea.polygonFromGridNodeSequence(Unknown Source)
        ... 10 more

java.lang.NullPointerException
        at org.osm2world.core.map_data.data.MapArea.getOuterPolygon(Unknown Source)
        at org.osm2world.core.world.data.AbstractAreaWorldObject.getAxisAlignedBoundingBoxXZ(Unknown Source)
        at org.osm2world.core.math.datastructures.IntersectionGrid.insert(Unknown Source)
        at org.osm2world.core.terrain.creation.TerrainCreator$1.perform(Unknown Source)
        at org.osm2world.core.terrain.creation.TerrainCreator$1.perform(Unknown Source)
        at org.osm2world.core.util.FaultTolerantIterationUtil.iterate(Unknown Source)
        at org.osm2world.core.terrain.creation.TerrainCreator.prepareSpeedupGrid(Unknown Source)
        at org.osm2world.core.terrain.creation.TerrainCreator.createTerrain(Unknown Source)
        at org.osm2world.core.ConversionFacade.createRepresentations(Unknown Source)
        at org.osm2world.core.ConversionFacade.createRepresentations(Unknown Source)
        at org.osm2world.console.Output.output(Unknown Source)
        at org.osm2world.console.OSM2World.executeArgumentsGroup(Unknown Source)
        at org.osm2world.console.OSM2World.main(Unknown Source)
this exception occurred for the following input:
org.osm2world.core.world.modules.WaterModule$Water@217f242c
camera or projection missing
Exception in thread "main" javax.media.opengl.GLException: javax.media.opengl.GLException: Unable to open default display, needed for visual selection and offscreen surface handling
        at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:271)
        at com.sun.opengl.impl.x11.X11GLDrawableFactory.maybeDoSingleThreadedWorkaround(X11GLDrawableFactory.java:669)
        at com.sun.opengl.impl.x11.X11GLDrawableFactory.canCreateGLPbuffer(X11GLDrawableFactory.java:295)
        at org.osm2world.console.ImageExport.writeImageFile(Unknown Source)
        at org.osm2world.console.Output.output(Unknown Source)
        at org.osm2world.console.OSM2World.executeArgumentsGroup(Unknown Source)
        at org.osm2world.console.OSM2World.main(Unknown Source)
Caused by: javax.media.opengl.GLException: Unable to open default display, needed for visual selection and offscreen surface handling
        at com.sun.opengl.impl.x11.X11GLDrawableFactory.getDisplayConnection(X11GLDrawableFactory.java:615)
        at com.sun.opengl.impl.x11.X11GLDrawableFactory$1.run(X11GLDrawableFactory.java:262)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:641)
        at java.awt.EventQueue.access$000(EventQueue.java:84)
        at java.awt.EventQueue$1.run(EventQueue.java:602)
        at java.awt.EventQueue$1.run(EventQueue.java:600)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:611)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

Tordanik · 2012-03-25 14:24:51

SunCobalt wrote:

Exception in thread "main" org.osm2world.core.math.InvalidGeometryException: outer polygon is not simple for this object: 1443708
(...)
Caused by: org.osm2world.core.math.InvalidGeometryException: polygon must not be self-intersecting

Dieses Problem tritt leider manchmal auf, wenn in den OSM-Daten Polygone mit Selbstüberschneidungen vorkommen. Es kann aber auch auftreten, wenn Knoten so nahe beieinander liegen, dass erst die Ungenauigkeiten bei der Fließkomma-Arithmetik zu einer vermeintlichen Selbstüberschneidung führen.

Bei dir konkret geht es anscheinend um dieses Objekt:
http://www.openstreetmap.org/browse/relation/1443708
Der einzige Way dieser Relation hat mehrere nah beieinander liegende, aufeinander folgende Knoten, etwa
1145360404 (46,1798770, 19,9983536)
und
1169621141 (46,1798768, 19,9983539)
mit nur ca. 3 cm Abstand voneinander.

Die Wahrscheinlichkeit für ein solches Problem ist umso geringer, je kleiner der Kartenausschnitt ist, den man in OSM2World öffnet, und je größer die Abstände zwischen den Nodes in diesem Ausschnitt sind. Natürlich sollte ich auf längere Sicht möglichst mit robusteren Algorithmen Abhilfe schaffen.

Kamera or projection missing
Exception in thread "main" javax.media.opengl.GLException: javax.media.opengl.GLException: Unable to open default display, needed for visual selection and offscreen surface handling
        at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:271)
(...)
        at org.osm2world.console.ImageExport.writeImageFile(Unknown Source)
(...)

Hier tritt der entscheidende Fehler erst nach dem Erzeugen der 3D-Modelle beim Rendern mit OpenGL auf. Hast du überhaupt schon mal erfolgreich rendern können? Ansonsten sieht es nämlich eher nach einem prinzipiellen Problem beim Zugriff auf OpenGL aus. Ist das ein Server oder Desktoprechner, und was läuft darauf?

SunCobalt · 2012-03-25 15:57:11

Tordanik wrote:

Dieses Problem tritt leider manchmal auf, wenn in den OSM-Daten Polygone mit Selbstüberschneidungen vorkommen. Es kann aber auch auftreten, wenn Knoten so nahe beieinander liegen, dass erst die Ungenauigkeiten bei der Fließkomma-Arithmetik zu einer vermeintlichen Selbstüberschneidung führen.
Bei dir konkret geht es anscheinend um dieses Objekt:
http://www.openstreetmap.org/browse/relation/1443708
Der einzige Way dieser Relation hat mehrere nah beieinander liegende, aufeinander folgende Knoten, etwa
1145360404 (46,1798770, 19,9983536)
und
1169621141 (46,1798768, 19,9983539)
mit nur ca. 3 cm Abstand voneinander.
Die Wahrscheinlichkeit für ein solches Problem ist umso geringer, je kleiner der Kartenausschnitt ist, den man in OSM2World öffnet, und je größer die Abstände zwischen den Nodes in diesem Ausschnitt sind. Natürlich sollte ich auf längere Sicht möglichst mit robusteren Algorithmen Abhilfe schaffen.

Oh. Das ist eine Corine-Land Cover Relation, wie sie sehr oft in Europa vorkommt. CLC geht bekannterweise nicht sehr sparsam mit Nodes um, die auch mal fast übereinander liegen können.

Tordanik wrote:

Hier tritt der entscheidende Fehler erst nach dem Erzeugen der 3D-Modelle beim Rendern mit OpenGL auf. Hast du überhaupt schon mal erfolgreich rendern können? Ansonsten sieht es nämlich eher nach einem prinzipiellen Problem beim Zugriff auf OpenGL aus. Ist das ein Server oder Desktoprechner, und was läuft darauf?

Das ist Debian/headless mit xvfb ohne richtiges X. Auf dem Rechner habe ich noch nie was mit osm2world gerendert, nur auf meinem W7 Desktop. Aber auf dem Desktop habe ich weniger RAM und die Shell ist so umständlich unter Windows.

Witzigerweise habe ich seit gestern mit osm2pov rumgespielt. Das ist nur recht sensibel was die BBox der OSM Daten betrifft. Da kam mir osm2world gerade recht. Aber wenns nicht geht, gehts nicht und ich verstehe natürlich, dass ich nicht der Standardanwender bin.
Nett wäre es, wenn osm2world eine *.pgw (Worldfile) mit erstellen könnte. Dann könnte man mit gdal eine Vergrößerungspyramide erstellen und das Bild über Mapserver in OL darstellen.

Tordanik · 2012-03-25 16:53:58

SunCobalt wrote:

Tordanik wrote:
Dieses Problem tritt leider manchmal auf, wenn in den OSM-Daten Polygone mit Selbstüberschneidungen vorkommen. Es kann aber auch auftreten, wenn Knoten so nahe beieinander liegen, dass erst die Ungenauigkeiten bei der Fließkomma-Arithmetik zu einer vermeintlichen Selbstüberschneidung führen.
Oh. Das ist eine Corine-Land Cover Relation, wie sie sehr oft in Europa vorkommt. CLC geht bekannterweise nicht sehr sparsam mit Nodes um, die auch mal fast übereinander liegen können.

Ja, das ist ein typisches Import-Artefakt, ist mir schon mal begegnet. Ein Mapper würde das wahrscheinlich nicht absichtlich so malen. Muss ich wohl mal sehen, wie man das Programm etwas toleranter gegen solche Situationen bekommt.

SunCobalt wrote:

Das ist Debian/headless mit xvfb ohne richtiges X.

Prinzipiell sollte das gehen, maps.osm2world.org verwendet praktisch dasselbe Setup (Ubuntu vs. Debian sollte nichts ausmachen). Irgendwie kommt mir diese Fehlermeldung sogar bekannt vor - eine Ursache könnte sein, dass der osm2world-Aufruf nicht den vom xvfb bereitgestellten screen nutzt. Ein erster Vorschlag wäre daher:

Starte xvfb mit -screen 0, also z.B.

Xvfb -screen 0 1024x768x24 &

Dann rufe OSM2World mit DISPLAY=:0 auf, also z.B.

DISPLAY=:0 ./osm2world.sh ...

Lass mich wissen, ob das was an der Fehlermeldung ändert.

SunCobalt wrote:

Nett wäre es, wenn osm2world eine *.pgw (Worldfile) mit erstellen könnte. Dann könnte man mit gdal eine Vergrößerungspyramide erstellen und das Bild über Mapserver in OL darstellen.

Das sehe ich mir mal an, hatte bisher noch nicht mit Worldfiles zu tun.

SunCobalt · 2012-03-25 18:19:46

Danke Tobias. So ein Worldfile ist kein Hexenwerk....sag ich mal so in meinem jungendlichen Leichtsinn

Ich probiere später noch ein wenig rum wenn ich wieder zu Hause bin. Momentan bin ich etwas ratlos, was mir dieser Weg sagen soll
http://www.openstreetmap.org/browse/way/107897539

Da gibts eine Fehlermeldung von osm2world. Allerdings sollte es sowas überhaupt nicht geben. Ein Node ist zweimal in einem Way.

Announcement

#51 2011-11-10 21:08:32

Re: Programmvorstellung: OSM2World

#52 2011-11-11 08:05:57

Re: Programmvorstellung: OSM2World

#53 2011-11-11 08:20:05

Re: Programmvorstellung: OSM2World

#54 2011-11-11 10:26:13

Re: Programmvorstellung: OSM2World

#55 2011-11-11 14:07:36

Re: Programmvorstellung: OSM2World

#56 2011-11-11 17:17:06

Re: Programmvorstellung: OSM2World

#57 2011-11-11 17:42:42

Re: Programmvorstellung: OSM2World

#58 2011-11-11 18:07:06

Re: Programmvorstellung: OSM2World

#59 2011-11-11 23:23:06

Re: Programmvorstellung: OSM2World

#60 2011-11-12 10:11:52

Re: Programmvorstellung: OSM2World

#61 2011-11-12 11:16:57

Re: Programmvorstellung: OSM2World

#62 2011-11-12 13:18:20

Re: Programmvorstellung: OSM2World

#63 2011-11-12 13:40:15

Re: Programmvorstellung: OSM2World

#64 2011-11-15 02:09:42

Re: Programmvorstellung: OSM2World

#65 2011-11-15 07:36:32

Re: Programmvorstellung: OSM2World

#66 2011-12-11 23:32:59

Re: Programmvorstellung: OSM2World

#67 2011-12-12 06:49:11

Re: Programmvorstellung: OSM2World

#68 2011-12-12 08:51:31

Re: Programmvorstellung: OSM2World

#69 2011-12-13 04:22:20

Re: Programmvorstellung: OSM2World

#70 2011-12-13 07:33:58

Re: Programmvorstellung: OSM2World

#71 2012-03-25 13:30:06

Re: Programmvorstellung: OSM2World

#72 2012-03-25 14:24:51

Re: Programmvorstellung: OSM2World

#73 2012-03-25 15:57:11

Re: Programmvorstellung: OSM2World

#74 2012-03-25 16:53:58

Re: Programmvorstellung: OSM2World

#75 2012-03-25 18:19:46

Re: Programmvorstellung: OSM2World

Board footer