[Routing] Tools for getting from OSM to a routable network

[Geoff Leyland]

Hi Peter,

Thanks for the quick reply!

On 18/09/2014, at 8:22 am, Peter K <peathal at yahoo.de> wrote:

> I would open source it and see what happens. Usually these kind of thing
> need a big effort to tune it in several areas but digging into others
> its project takes also lots of work from your side of course.

Yes - there’s both quite a lot of work on the tool itself, and there would be quite a lot of work to adopt another solution.  Since you’re with Graphhopper, could I adopt your toolset?

> Which language is it written in?

It’s written mostly in LuaJIT, a very fast, tiny scripting language (think Python with no batteries and close to C speed).  This offers some advantages: quick development, relatively small code, and one disadvantage I’m hitting at the moment - restricted memory use.  There’s a very good way around this: a top-notch FFI, but that’s some of the work I’m assessing.

> Will it do routing too or just the data creation?

Well, yes I use it for routing, but not driving directions.  I use it for computing distance matrices for passing to vehicle routing problem algorithms.

However, I’d like to go for something of a “unix philosophy” and break it into a pipeline: my goal would be to have a tool that gets from OSM to some relatively neutral “routable network format”, then a tool from, say, a list of addresses to another relatively neutral distance/time/cost matrix format, so I guess as a first step I’m thinking about the OSM -> routable network format.

> Then how fast is the import and routing?

Importing the New Zealand map from geofabrik from OSM->memory mapped ready-to-route takes about a minute on a 2.2GHz i7.

Routing is pretty quick because it’s memory mapped data, but not that flash because I’m only using a multi-sink Dijkstra for the routes.  VRPs tend to all pairs of addresses (not nodes) in a single city, so I’m not sure that some of the reach-based (and more) routing algorithms would offer a lot.  I could well be wrong.

Cheers,
Geoff