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.
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.
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
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.
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.
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.
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.
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.
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 
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!
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.
Logo, denn dein Programm ist mir mitlerweile doch ein wenig groß geworden um da spontan durchzusehen. Vor Feb wird das aber def. nichts 
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)
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.
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?
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.
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.
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.
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.
Das sehe ich mir mal an, hatte bisher noch nicht mit Worldfiles zu tun.
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.
Its a Level-8-Bug.
Warum nicht? Sowas habe ich auch schon gezeichnet. Wenn man service auf dem Parkplatz einzeichnet kann man auch gleich um die Ecke zeichnen und irgendwann kann sichd er Weg wieder schneiden. Da gabs noch nie ein Problem.
Sorry, mein Fehler. Hab dreimal um die Ecke gedacht und mich dabei verirrt. Muss also an etwas anderem liegen