validated/accurate 3d model of roads?

Hi All,

I’m doing some research on vehicle convoys, and have been using OSM data around a city in UK to base things on. To help visualise whats going on, both from the AI controlling the convoy, and the vehicles themselves, I’ve been using a 3D viewer based on jmonkeyengine to view things.

So far I’ve used osm2world to create the 3D .obj model, which creates a really good looking visual model, but I seem to be having some accuracy issues. I did some more tests with that today on the latest build, so hopefully can solve it.

But, wondered if anyone else has done something similar, to that level of accuracy? With vehicles on roads, it becomes visually obvious i theres more than say 0.5m, and with things like lat/lon - UTM conversions I could see that being introduced.

So, if anyone’s managed it, keen to hear more!


I’m not completely clear what you’re asking, but in case it helps, did you see the SuperTuxKart demo on another thread here?

Hi VinieB,
nice to hear, that there is reasearch on the 3D aspects of OSM :slight_smile:

But to be honest, as Olivers says, I don’t get the point of what you are asking in detail.

You write about vehicles, so I guess you are doing some kind of routing, enhanced by a 3D digital elevation model (that is AFAIK not part of OSM itself). Some projects, as follow this approach.
On the other hand, you write about O2W and .OBJ export, that is used to export buildings and micromapped areas, but you will lose all semantics?

Would be cool to get some more details, so we might help with some more informations :slight_smile:

You know traffic simulation already?
Oh and there is a research page, where you can easily add your publications:

Hi All,

Cool, thanks for the replies. And SuperTuxKart looks awesome… that gives me some ideas :slight_smile:

Sorry I didn’t provide enough detail in the first message. I find it hard to guess just how much I need to write without boring people!

So, we have a middleware framework (, where I have an AI engine (Jason - controlling a number of vehicles acting in a convoy. The AI part subscribes to vehicle position data, and outputs control signals (stop, turn, accelerate, etc) to the vehicles, handling the reasoning about what to do. In the current version, vehicles are simulated by a very simple java app, publishing their position data and subscribing to control messages. Then I have a 3D engine which subscribes to all of this data, so you can view whats going on. There’s a few additional blocks like analysis tools and database logging too.

This last week, I’ve been integrating SUMO, to provide better traffic into the simulation, and I think I’ll replace the simple vehicle java app with vehicles in SUMO, so the AI can control these instead.

To maybe make more sense, here’s a video: - its a combination of showing what’s going on in the mind of the AI agents (e.g. their calculated collision volumes shown in red), what beliefs have been updated, and that sort of thing.

Now, the problem I have, is the alignment of the 3D model (a .obj file generated from osm2world based on the .osm data) to the vehicle positions. As the AI part is currently sending vehicles to x,y positions calculated from the OSM data, the vehicles should always appear on the road. But, they don’t e.g. . The blue shapes are when the AI agents have new beliefs on waypoints, and I’m pretty sure these locations are right - both checking the OSM, and overlaying on googlemaps. But you can see in that image, it looks a bit skewed.

I’ve nearly finished SUMO integration too, and when I checked yesterday, I get the same issue. So, I think its something in the osm->obj conversion. Maybe something in osm2world, but I wondered in general if anyone has done some sort of validation, of accuracy of 3D models generated from osm.

I guess usually people would just be interested in does the model look about right, rather than is everything in the right place to +/- 0.5m. So wondered if anyone had been able to produce such models?


sounds like a great project and it’s nice you use OSM2World for the 3D modelling.

I think I do not fully match that category, however, I’m the maintainer of the OSM2World-Slippymap and contributed a small amount of code to OSM2World itself.

First of all I think the “bug” should be somewhere in the projection code and this code is used for all exporters of OSM2World (i.e. obj-output and Slippymap-output both use the same code). If you have a look at the slippymap, the code works that far, that two tiles match at the border (you’d see a +/- 0,5m displacement). However, there might still be a problem with a general displacement over the whole world!

To narrow down the problem, I’d be interested in two things: First of, is the displacement everywhere the same or does it change with the position on the map? Second, may we see your code or the name of the projection code you use? If you e.g. use UTM, a displacement to WGS84 is to be expected I think (however, 0,5m sounds a bit large :)).


Thanks! And yeah, osm2world is almost perfect for what I need, and I’m a big fan of opensource - all the components I’ve used are opensource as is the code I’ve written :slight_smile:

Well, 0.5m might have been a bit of an underestimate, as I think the error varies. Infact, my guess is that the error linearly increases as you move away from some point which maybe the .obj is centered on.

I’ve got a couple of examples, the first is here . This is the standard obj I’ve been using, and covers about 1.5km by 1.5km. This far zoomed out, it doesn’t look so bad, but in the earlier screenshot ( thats pretty big, maybe 2 road widths to give it context.

Now, I used the latest osm2world build, as from emails with Tobias there was a new projection approach put in. And this time, I get this: - sorry the colours aren’t so clear here, the route is shown in red. The interesting thing here, is that the error looks consistent on the east of the route. Infact, in the 3D view, I added some controls to shift the xy of the obj, and to stretch/shrink on the xy axis too. If I shrink by about 0.93 on the east-west axis, it looks pretty good. But, when I tried this in earlier osm2world, I still didn’t get a great fit.

The other thing worth mentioning, is coordinate system. So, use a local xyz with meter units. From the .obj generated from osm2world, I run it through the openscenegraph osgconv as that seems to make the model appear better in the 3D engine, and then load the .obj in the renderer. I’ve got xy offset values where I’ve put a vehicle at a known location, and aligned the .obj to that position by shifting those offsets. So that’s why the bottom south-west of the route seems to align so well.

So I think, I’m pretty much using UTM, just with the positions all zero’d to a local position, to keep all my numbers a bit more manageable. I did wonder if it was some lat/lon zone type thing, but then I wouldn’t have expected to see it having that big an impact over a small 1.5k area… but, I’ve never really looked into that conversion stuff in huge depth.

If there’s any code I can show that would help then let me know, but I’m not really handling any projection conversions as I thought everything was shifted to UTM.

Oh yes, one other thing I checked, if I go to the lat-lon in the osm2world GUI, for the converted UTM coords of those waypoint positions shown in the url links, it appears in the right place.


sorry for my late reply.

The coordinate system (at least the version from the website) is using meter units, too. And I’m quite sure the values are accurate. From what I understand the osgconv just converts the obj-file to another format which shouldn’t harm the corrdinates.

What I still don’t understand are your coordinates and where they’re coming from. The original values you get are lat/lon-values? And you put it in some lib that presumably outputs some xyz-values in a coordinate system with meter units?

I have to check on that topic again. At which point do you zero to a local position? Is this with lat/lon-values or with the converted meter unit values (in the first case this would explain the problem as you may not center lat/lon-values)? And regarding the zone: I’m not an expert in those transformations by any means but if you’re using another zone for conversion as your lat/lon values are in, an abberation of 1 meter and more is not unusual.

Well, I’d mainly like to have a bit more explanation on what’s happening. Especially your route data. Where’s it from and more important, in what format is it in? Is it lat/lon? If yes, what lib/code do you use to translate it into your meter units? As I understand it there are two parts involved: 1. A UTM-lib to convert lat/lon to some meter-values, 2. your “centering” code to shift all values near (0,0)?

Sorry for being slow to catch on that topic, but I really hope we get this going as I’d really appreciate it, if you’d use osm2world for your application :slight_smile:


Sorry for my slow reply in return - was busy trying to integrate SUMO traffic sim into this so that I can have decent background traffic :slight_smile:

I started another scenario, on the M25 motorway around London, and regenerated a 3D obj from osm2world for that, and have the same problem again… so then I checked if there was anything more on this thread.

So, I’m trying to simplify the test case here, as I think the 3D view/engine I’m using is adding confusion… and I think the error is in the generated .obj file.

From what you said, I realised something like the Blender tool should be able to help test - it would open the .obj file using real world 1m coordinates I think…

My test hypothesis, is this:

  1. Take an OSM map file of city of interest
  2. Pick two coordinates at obvious positions, and obtain the UTM coordinates of those points
  3. Find the distance between those two points in the x and y axis
  4. Load the osm2world model built using that OSM, and produce .obj
  5. Open .obj file in Blender (or any known 3D tool which you can extract coordinates from)
  6. Find distance between coordinates of the previous two points used
  7. Check they match

And I think this proves a problem… unless I’ve made a bad assumption somewhere?
Here’s the bottom corner in blender (-307, -281):

And the top corner (-198, 978):

So, I’ve tried to explain my working on another pic below. I think that suggests there’s about a 13m error… I’ve also been looking at the code, it looks to me like its currently using, but I think even the version of the .obj file I’d built on an earlier (maybe pre hackmap projection) still had similar issues. The other interesting thing is, if in the osm2world gui, you use the camera, set to coordinate, and enter the lat lon coords used here, it appears in the right place. Which tells me, the OSM data is fine, and lat lon is fine, but something is going wrong in the conversion / production of the .obj file?

Hopefully thats useful info? If I can provide any more let me know, I think this nicely gets rid of any other factors like what coordinates i’m using… The osm file is available here if it helps at all


Hi All,

Good news! Problem solved! Well… I hope… it looks solved anyway.

I swapped out the code in HackMapProjection (to hack it even more :slight_smile: ) and used this guys coord conversion


Everything aligns now - I’ve not had to stretch or skew the .obj file at all.

So, if anyone is interested in the accuracy possible from osm2world… its very high :slight_smile: