Hi tried some variations and at least for me, the value 0.01 is more what I expect a wood area to look like. What you say, should we change the default value, or do you already map very small wood areas with a lower density?

building:roof:shape=pitched is very popular (about 25000 according to taginfo)
It is similar to gabled, but it seems pitched extends horizontally while gabled extends the roof line over the building outline.
http://en.wikipedia.org/wiki/Roof_pitch
http://en.wikipedia.org/wiki/Gabled_roof

for now one could just handle pitched as gabled imo. support for Crow-stepped gable would be awesome :)

WorldObjects should be able to add lights to the scene. This could be used for street lights, buildings and so on.

This may not be supported by all export formats, but would be possible at least in OpenGL, COLLADA and POVRay.

Originally reported in #26.

I have no idea, why building part http://osm.org/browse/way/215486583 is not rendered with one level height and about 6 meters from the ground and why the roof is not grey.
The building part
http://osm.org/browse/way/214478959 is in the same building and renders nicely (has no min_level so i can see the first part do not render min_level.

There is some black cloth in in the appletree texture

http://www.openstreetmap.org/browse/way/79058116
is rendered as a street. I think it is the highway=platform tag.
Thanks for your nice software and especially the slippymap.

Holger, tagging Aachen :)

Thought this could be funny, if we could export the world in a specific scale to Lego ;)
http://www.ldraw.org

No don't want to try that, just a reminder for me....

Animated models would be an interesting feature for future versions of OSM2World. This could include both non-interactive (clocks, swaying trees, ...) and interactive (opening a gate, ...) animations.

This may not be supported by all export formats, but would be possible at least in OpenGL and COLLADA (possibly interactive) and POVRay (only non-interactive).

Originally reported in #26.

The placement of trees for any wooded area should only depend on the area's latitude and longitude coordinates and its OSM id, not on the projected local coordinates.

Solving this issue would prevent incomplete trees at tile seams.

Currently we miss piers and similar equipment to dock ships etc. Maybe we can start with something simple, so just ways in the same z-order as the waterlevel? Later on, we might working on getting piers above the waterline.

Well ok, this idea is strange ;)
What I request would be an possibility to convert a GPX track (say a motorbike) to some line/paths objects in the scene coordinate system, that can be used later on, to animate cameras etc.

Another application would be to use eWorld to convert netlists to animation paths. This can be used, to control the behaviour of swarms like pedestrians or cars within the final scene.

all flat roofs have the same colour.

Even if thats not a problem of O2W, during my surveys in Rostock I noticed a few simple things missed to bring characteristics to buildings:

• pillars (with describing their shape, height and connectivity)
• roof overlengths (that could become a simple roof:overlength=0.3 to affect the whole building)
• roofs that already look aside on the sides of the top level and so are very steep
• balconys (unkown if this a real building part, as to me it has a more outdoor characteristics. Anyway they are mostly very colourfull and allow a quick recognition)

Hi, what do you think about making the tree generator working on park and cementry areas, too? At least here in germany this areas contain usually trees, or do we recommend to tag a dedicated natural=wood area?

As SBM introduces different colour=* attributes with the definition of colour=*, I tried to make use of spelling colour names e.g. red. blue, yellow.
I noticed, that O2W interpretates this quiet different than the W3C specs (a bit darker and less shiny).

This might be a good intention, as the world doesn't look like playmobil ;) but causes confusion, as the mapper now needs to enter HTML colour codes.

So maybe we can make this darker layout optional to fullfil the offical specs and allowing people to get realistic colouring?

P.S. colour=silver doesn't seem to be recognized?

Can we please add an menue entry, that holds the most recent osm files? As O2W is currently instable at least here, it's annoying to use the filepicker again and again. IMHO most designers will use GUI to control the tool, so might be useful?

Currently O2W has problems with buildings that have an L-groundshape and that have gabled roofs.

Here an example:
http://www.openstreetmap.org/?lat=54.07847&lon=12.114041&zoom=18 (Waldorf Kindergarten)

Even if the desired model can be enforced using a single building:part for one part of the L, this won't fix the diagonal connection between both shapes in the inner corner of both parts.

Currently O2W seems to produce a lot of clipping problems, especially here:

• Landuse: Sometimes an area is covered with multiple polygones in exported OBJs
• Highway crossings: The ends of highways are connected by overlapping them, which needs to be a more clean design e.g. a n-gon shape who acts as central "connector hub" so the road box can seamlessly connected

Please add an possibility to select which objects should be exported and with what level of detail. For example, should buildings get very simple geometry (ground shape with height) or enriched with building_parts and so on...

Background:
The usage of 3d models is quiet different. While static renderings would benefit from max details, interactive games or 3D printing need very limited geometric details (for speed and as only solid structures can be printed)

I'm not sure if O2W is currently able to store more complex shaders, but what would be really cool is to get esp. reflections (metal) and transparency (glass). Of course this might look strange with window textures (or they need dedicated alpha channels for this properties), so optional would be a cool idea.

But I guess this needs refactoring, uh?

The slippy map does not support glass roofes.

As Simple Building Model introduces various possibilities to style building parts, it suggests to make use on the colour=* tags (UK spelling) which is absolutly right. But as here in Germany for example the "color" term is much more popular, the mapper might use it instead.

So I recommend to support all color attributes with simple "color" as legacy fallback option and maybe to report the misspelling of the tags, if found.

For relation 2788481 of Bremer Dom which looks correctly modeled the OSM2World converter produces weird results

During my survey I noticed a few objects still missing:
-barrier=gate
-power=cable_cabinet
-amenity=telephone (esp. for charecteristic providers)
-vending=cigaerttes
-bus_stops (but noticed it in current GIT?)
-traffic lights
-chimneys (with defining material and height)
-DSLAMs (no good tag currently, some use communication = outdoor_dslam)
-Postlagerungskästen (no good tag yet, some use storage=mail)

Maybe I can submit some of them as patch if I play around with the street furniture module...

The screen should contain basic instructions and tips e.g. WASD key control, ....

Maybe I can do this one and submit an patch.

If there is a building part where people can walk below, I usually use tunnel=yes, to indicate that the sky is invisible here (e.g. cause GPS to get no position).

Unfortunatly, O2W seems to interpretate tunnel=yes as a tunnel one level below and so create a tunnel that is one level down, even if this tunnel way is covered by a building/buildingpart that has min_height attribute to indicate that there is space to walk along and no need of a tunnel.

Example:
Please see http://www.openstreetmap.org/?lat=54.077592&lon=12.11513&zoom=18
(part is labeled "Säulengang" and stays with pillars in the air).

If you load an area at the sea (e.g. Rostock Warnemünde ), your dump contains the full waterways/coastlines along the land, even if it just touches your dersired area. This slows down O2W, as it tries to figure out all the area, even if this is outside the BBOX.
Maybe we can add an artificial cut step, that applies the BBOX dimensions to this kind of big polys?

We should make sure, that a few very basic attributes are accepted for all kind of objects, to allow a local customisation by mappers. I suggest:
-color
-material
-height
-width

Furthermore, I suggest to find a pretty simple tagging schema to describe the basic ground shape of node objects, for example chimneys, lamps, artworks, ... . Maybe something like shape=square
Would be nice to see this attibute set beeing supported even for building=entrance or specifying windows?

I tried to get O2W to compile within Eclipse IDE. Sadly this doesn't work for me, here is how I tried:

1. Create a new Java project
2. Fork the O2W git and import this new repo to the freshly started project folder
3. Try to fix build path
4. Invoke Ant build -> ok

Unfortunatlly I can't add ./lib to the build path of the project:
Project- Build path - Libraries - Add jars
But here you can only add single .jar and not a whole path?

Even it will still take some time, till the whole global community joins the 3D tribe, there will be an i18n problem:
Currently we script static models that we design like we know them from our local cities (mostly german ones I guess). But later, there we might take the location of the OSM scene into account, as a postbox in the UK looks quiet different than the usual ones in Germany. In this case it can be toggled by the operator=* tag, but this won't work with traffic lights and general city furnitures.

So we might reflect this distinguation in the architecture someday...

Hi

You wrote in the wiki "There are several places in OSM2World where very inefficient algorithm placeholders are used". Can you be more precise? I plan to use it on files containing the data of entire towns, maybe I can give you some help.

The osmosis component strugles, if you save/load your .OSM with more than only one area. But if you use O2W as 3D viewer, while parallel editing in JOSM, this is quit annoying, as you need to download an area in one piece, instead of improving parts of it, step by step.

Even if this is pretty hard, maybe we can someday add an possibility to enable more complex objects, than just plain 3D geometries and textures
*llight - can be useful for citylights and buildings of course
*animimations - can be used for clocks or to add functionality to modesl (as opening gates, ...)

Not sure if every format allow such features, but at least COLLADA (I know this is where I need to pay attention) can

I find it is a good and simple idea to add ground-textures for things like this in the map:

• landuse=farmland
• landuse=meadow
• landuse=grass
• landuse=quarry

The map would become more textures, and the techniq for this is simple, because it is already implemented (there are only 2d-textures on the ground)

Thanks

The OSM2World viewer launches and immediately quits on an iMac with Mac OS 10.8.1 Mountain Lion and Oracle Java 7.

Java version:

java version "1.7.0_06"
Java(TM) SE Runtime Environment (build 1.7.0_06-b24)
Java HotSpot(TM) 64-Bit Server VM (build 23.2-b09, mixed mode)

Command line output:

No parameters, running graphical interface.
If you want to use the command line, use the --help parameter for a list of available parameters.
Exception in thread "main" java.lang.UnsatisfiedLinkError: no jogl in java.library.path
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860)
    at java.lang.Runtime.loadLibrary0(Runtime.java:845)
    at java.lang.System.loadLibrary(System.java:1084)
    at com.sun.opengl.impl.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:189)
    at com.sun.opengl.impl.NativeLibLoader.access$000(NativeLibLoader.java:49)
    at com.sun.opengl.impl.NativeLibLoader$DefaultAction.loadLibrary(NativeLibLoader.java:80)
    at com.sun.opengl.impl.NativeLibLoader.loadLibrary(NativeLibLoader.java:103)
    at com.sun.opengl.impl.NativeLibLoader.access$200(NativeLibLoader.java:49)
    at com.sun.opengl.impl.NativeLibLoader$1.run(NativeLibLoader.java:111)
    at java.security.AccessController.doPrivileged(Native Method)
    at com.sun.opengl.impl.NativeLibLoader.loadCore(NativeLibLoader.java:109)
    at com.sun.opengl.impl.macosx.MacOSXGLDrawableFactory.<clinit>(MacOSXGLDrawableFactory.java:53)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:186)
    at javax.media.opengl.GLDrawableFactory.getFactory(GLDrawableFactory.java:108)
    at javax.media.opengl.GLCanvas.chooseGraphicsConfiguration(GLCanvas.java:520)
    at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:131)
    at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:90)
    at org.osm2world.viewer.view.ViewerGLCanvas.<init>(Unknown Source)
    at org.osm2world.viewer.view.ViewerFrame.<init>(Unknown Source)
    at org.osm2world.console.OSM2World.executeArgumentsGroup(Unknown Source)
    at org.osm2world.console.OSM2World.main(Unknown Source)

The version producing the error is an hourly build from August 2012 (development for 0.2.0 release), after the migration to JOGL 2.x.

On the same system, OSM2World 0.1.9 - using JOGL 1.1.1 - will show the menu bar of the viewer, and the statistics feature as well the OBJ export can successfully be used. However, creation of the GLCanvas will fail with an exception. ("Exception in thread "Timer-0" javax.media.opengl.GLException: java.lang.NoClassDefFoundError: apple/awt/ComponentModel")

[This is an error reported by a user of OSM2World, it has not been reproduced by a developer yet.]

The export to multiple OBJs seems to break the material definitions.

Steps to reproduce:
Load entire area within the "Südring" in Rostock that contains a lot of 3d tagged objects
http://www.openstreetmap.org/?lat=54.07568&lon=12.1137&zoom=17
Do Directory OBJ export with the default 10.000 verts option.
Load all this .OBJ in Blender3D and see, that some of them are just colored grey.

I have no idea hwat causes this behaviour, as mtllib is in every .obj file.

Hi, the newest rendering of the O2W web map contains hedges with just black colour oO
http://maps.osm2world.org/?zoom=18&lat=54.07464&lon=12.10841&layers=B0TTFF

I guess this is a bug?

If you press CTRL+R O2W reloads the OSM file. It would make sense, if it would reload the properties files, too. So you can easily/quick visualise/compare how changed properties (e.g. wood density) affects your scene.

In my renderings, simple paths appeare mostly the same, as usual footways or roads. This is odd, as they often go through areas and are (at least in my interpretation) only with a very low priority. So can we decrease the with and tweak the appearance, please?

I built the ways http://osm.org/browse/way/215433273 and http://osm.org/browse/way/84159471
they are not rendered as expected.
I think it is related to the combination of
building = roof
and
building:min_level = xy

http://commons.wikimedia.org/wiki/File:Aachen_RWTH_IBAC_2.jpg is a photo of this roof construction. The walls are not in osm till now.
Thanks for your work!

Hi,
I try to create levels for Supertuxkart with this toolchain:
OSM2World -> Blender3D -> STK RDK -> Supertuxkart

That works well, but there are still problems with texture support.

In short, the building textures doesn't get colorized and buildings with just an single color are white.

There are some suggestions, as using vertex colors or synthesising colored textures:
http://forum.freegamedev.net/viewtopic.php?f=18&t=4295
So what do you think?

Reloading the configuration file does not reset materials to their default untextured state if a texture was previously defined. Exchanging the texture with a different one works fine.

Steps to reproduce:

1. start the viewer with a config file containing a texture definition for at least one material
2. open an OSM file that produces a scene using that material
3. remove the texture definition completely from the config file
4. reload the OSM and configuration files. The texture will still be used for the material.

O2W already synthesizes single trees in wood areas. Maybe someday we can add more such (optional) behaviour for various areas:

• scrub - filled with small faces that show different heigher/lower plants
• allotments - quiet complex, as an area is partitioned into a bunch of pices ("Parzellen"). Would be demanding to get an algorithm, that uses the path within to create such an partition :)

yes, this is luxury stuff, but let's keep it in mind for further developments....

There seems to be a bug in the current SVN which causes a crash on my usual workflow:

1. Open JOSM while editing, save a local .OSM
2. Open the .OSM with O2W
3. Do further edits and reload O2W from time to time, to check the results

Sadly this results in crashes from time to time (~ <20mins) but I have no idea how I can assist you on finding the bug.

Here is the console log: http://pastebin.com/DQMFrHby
Here is the stack trace dump: http://pastebin.com/9vnFXxPd

Don't know if this is possible, but I notice that O2W doesn't support objects that are tagged with multiple tags.

Example:
A small pool that is protected by a fence:
natural=water, barrier=fence

I know it's possible to solve this issue by modelling it into 2 single objects, but this would be "tagging for renderers", doesn't it? I accept that this style of tagging is bogus, as it's pretty hard to assign further attributes on one of the both elements (e.g. is height=* for water or the fence?) But currently this tagging style is out in the wild....

Hi

Your project would be easier to use with Eclipse if you provided a .classpath file like this one:

< classpath >
< classpathentry kind="src" path="src"/ >
< classpathentry kind="src" path="test"/ >
< classpathentry kind="lib" path="lib/configuration/commons-collections-3.2.1.jar"/ >
< classpathentry kind="lib" path="lib/configuration/commons-configuration-1.6.jar"/ >
< classpathentry kind="lib" path="lib/configuration/commons-lang-2.6.jar"/ >
< classpathentry kind="lib" path="lib/configuration/commons-logging-1.1.1.jar"/ >
< classpathentry kind="lib" path="lib/guava/guava-r08.jar"/ >
< classpathentry kind="lib" path="lib/javaproj/javaproj-1.0.6.jar"/ >
< classpathentry kind="lib" path="lib/jewelcli/jewelcli-0.6.jar"/ >
< classpathentry kind="lib" path="lib/jogl/gluegen-rt-natives-linux-amd64.jar"/ >
< classpathentry kind="lib" path="lib/jogl/gluegen-rt-natives-linux-i586.jar"/ >
< classpathentry kind="lib" path="lib/jogl/gluegen-rt-natives-macosx-universal.jar"/ >
< classpathentry kind="lib" path="lib/jogl/gluegen-rt-natives-windows-amd64.jar"/ >
< classpathentry kind="lib" path="lib/jogl/gluegen-rt-natives-windows-i586.jar"/ >
< classpathentry kind="lib" path="lib/jogl/gluegen-rt.jar"/ >
< classpathentry kind="lib" path="lib/jogl/jogl-all-natives-linux-amd64.jar"/ >
< classpathentry kind="lib" path="lib/jogl/jogl-all-natives-linux-i586.jar"/ >
< classpathentry kind="lib" path="lib/jogl/jogl-all-natives-macosx-universal.jar"/ >
< classpathentry kind="lib" path="lib/jogl/jogl-all-natives-windows-amd64.jar"/ >
< classpathentry kind="lib" path="lib/jogl/jogl-all-natives-windows-i586.jar"/ >
< classpathentry kind="lib" path="lib/jogl/jogl.all.jar"/ >
< classpathentry kind="lib" path="lib/jts/jts-1.11.jar"/ >
< classpathentry kind="lib" path="lib/osmosis/commons-compress-1.2.jar"/ >
< classpathentry kind="lib" path="lib/osmosis/osmosis-core-0.40.1.jar"/ >
< classpathentry kind="lib" path="lib/osmosis/osmosis-pbf-0.40.1.jar"/ >
< classpathentry kind="lib" path="lib/osmosis/osmosis-xml-0.40.1.jar"/ >
< classpathentry kind="lib" path="lib/osmosis/osmpbf-1.1.1-754a33af.jar"/ >
< classpathentry kind="lib" path="lib/osmosis/protobuf-java-2.4.1.jar"/ >
< classpathentry kind="lib" path="lib/osmosis/xercesImpl-2.9.1.jar"/ >
< classpathentry kind="lib" path="lib/trove/trove-111118193120.jar"/ >
< classpathentry kind="lib" path="lib/trove/trove-3.0.1-src.jar"/ >
< classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/ >
< classpathentry kind="con" path="org.eclipse.jdt.junit.JUNIT_CONTAINER/4"/ >
< classpathentry kind="output" path="bin"/ >
< /classpath >

Best regards and keep up the good work.

Hi,

I've started improving the 3d tags on the donauturm (http://osm.org/go/0JrJz8UYB--) After my last tries a few weeks ago, I've now found the kendzi3d plugin and actually mapped it "correctly" according to its output. I've cross checked with osm2world and the stem of the donauturm is missing. I guess it is "obscured" by the min_height platforms above it? Or did I tag something wrong?

Thanks for the cool map!

Just an idea and the question, if you could imagine if that would be possible to add:
An algorithm that add street signs shortly after crossings?

1. follow street network
2. trigger if a way splitsup
3. oh it's a footway dedicated to pedestrians and bicyclists
4. pick the right image from Wikipedia depending on country
5. create an pole with the mounted sign shortly below the crossing near the way
6. continue following the road network ...

With the SuperTuxKart community, I play around to synthesize levels for this SuperMarioKart clone. They uses blender3d as design studio, so I imported textured multi .OBJs. Sadly there seem to be a problem, that the vertex colours of the building (that STK doesn' make use) "hide" here the real textures:
http://forum.freegamedev.net/viewtopic.php?f=18&t=4016#p41251

so is there anything, we can do to reverse the order, or disable temporaly the vector colours export?

There occure some problems with gabled roofs.
For examle the roofangle is not supported at two or more level buildings.