Saturday, 12 May 2012

OpenStreetMap for BVE routes

A.S. It looks like OpenBVE's Michelle has exited the stage in just the last few days. I doubt the whole back story is public yet, but let's say thanks and wish her well for whatever she's up to now. Still, this means that the OpenBVE community is in a bit of turmoil now. Who takes on the work now? I hope reason prevails and this "only serious developers need apply" / "we don't need outside interference" elitist attitude, expressed on the BVEStation forum, dies quickly. We really don't need another cathedral vs bazaar experiment now - the bazaar has clearly won. Now where is the OpenBVE git repository?

I would like to be able to drive the local suburban train, a Metrorail 5M2A, from Cape Town station to Simons Town. Especially the latter half of the route would be picturesque.

It's painstaking work to write up a BVE route by hand. A route is organized in fixed-length blocks, typically 25m, and "things happen" at the boundaries between these blocks: curve radius changes, cant changes, station starts and stops. Directly measuring curve radii and adding those to the route will result in a route that has roughly the correct shape, but it will be difficult to get the route to line up exactly with the modelled territory. Here's an example of this divergence you get without feedback:

That's a part of Cape Town - the so-called "City Bowl". The route that veers off westwards is one I originally wrote by eye-stimating distances and curve radii from satellite imagery retrieved from a certain very popular online mapping service. You can see that the route has roughly the right shape, but relatively small errors in distances and curve radius make it diverge from where it should be.

To get the route exactly coincident on the modelled territory, I decided to compare the route map with OpenStreetMap data. The OSM data of my city is well tagged, so it was easy to teach PHP to pick out railway=rail "way"s and draw them on a PDF. Just because it was easy, and seemed like it would be pretty, I also made it draw other ways in the lightest grey that is still visible.

Future directions?

It's still painful to have to fiddle the curve radii, segment by segment, until the route exactly coincides with the background map. It should be possible to use the extant way data to generate a whole run of track, interrupted only by the random breaks in data from the OSM contributors. Perhaps I should make a command-line tool that generates a route "skeleton", by accepting a list of way IDs and gluing them together with some curve-fitting trigonometry.

As an extension of such way-gluing, it could be useful (if not perfect) to transform road ways into asphalt road surface objects, perhaps some generic kerbs and road markings as decorations. OSM data is probably too sparse to be able to infer a whole lot of building objects, but even just a few scattered ones might already make the route a lot more fun to drive.

Apparently the XML export format is deprecated, and there is a "better" format, a binary one. I didn't feel like reading up on the binary format, and just wanted something that worked now. The benefits of using the binary format include being able to export larger areas and future-proofing (for when XML goes away).


You should carefully consider whether using OSM data as a template against which to align your route makes your route a derivative work of the OSM data. On the one hand, tracing a map seems like the sort of thing that passes the "derivative work" test, and on the other, facts aren't necessarily copyrightable. I don't know which side is more persuasive to me, so for my own routes I will assume that my route is a derived work, and release them under a license compatible with that of OpenStreetMap data. You could do that too if you don't want to think too hard about it.

P.S. Until there's an "official" project repository, you could do worse than cloning Debian's Alioth repository:
git clone git://