Programmvorstellung: OSM2World

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

SunCobalt · 2012-03-25T12:30:06.000Z

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-25T13:24:51.000Z

SunCobalt:


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-25T14:57:11.000Z

Tordanik:

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:

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-25T15:53:58.000Z

SunCobalt:

Tordanik:

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:

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:

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.