[OSM-dev] GSoC 2016

Peter Barth osm-peda at won2.de
Sun Mar 13 15:13:28 UTC 2016

Hello Kunal,

Kunal Khandelwal schrieb:
> "Several people have toyed with the idea" - can someone please inform me of
> the earlier attempts in this regard?

The first one to try was Matthias (see http://wiki.openstreetmap.org/wiki/SuperTuxKart).
The second one was me (or actually my wife). I produced some patches for
OSM2World, but I'm not sure all of them had been merged by Tordanik.
Anyway, there's a (German) talk by Tordanik about that work

I'm sure Tordanik will supply you with the patches and the text files 
and python scripts that I used.

> The problem statement seems straightforward to me, are there any hidden
> challenges involved apart from relying on multiple technologies?

There is more to it than just the technologies. There are several
problems that need to be solved manually right now. To name some of

* The track itself has to be a special kind of area to work with STK
  (SuperTuxKart). So this is manual blender work right now. But it would
  be possible to infer the track from OSM data as well. (imho the most
  important task)
* Objects in OSM2World are all the same, though they should behave
  differently in STK: You should be able to drive through small hedges, 
  (open doors), (billboard) trees,... You should "die" when you drive
  into water. You should be slower on gras than on asphalt. And so on.
  This is currently manual work (some of that is handled in the python
* Placing STK extras (bananas, the boxes, speed arrows,...) is manual
  work, while it could also be handled in OSM data
* The huge number of triangles makes the game (or loading of it) slow.
  This could be solved by reusing models (e.g. for trees) instead of
  repainting them.
* Some other shortcomings of the OBJ file format make it difficult to
  produce really good STK tracks. This could be improved with e.g.
  writing meta data from OSM2World and make use of it in STK/Blender.

There's probably more to it and you should have a look at the python
scripts or even give it a try and make a short track yourself to see the
current problems. I think the main task would be to infer the STK track
from OSM data as this is the most difficult and cumbersome work.

Hope that clarifies a bit better what the problems are and I'll tell
Tordanik to send you the python scripts.


More information about the dev mailing list