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

[Frederik Ramm]

Hi,

On 09/17/2014 10:11 PM, Geoff Leyland wrote:
> It all works nicely for where I come from (New Zealand).  However, I’d have to do a bit of work to get it work it larger countries.

The big thing that nobody really has a good solution for (yet) is
continuous updates on a routing graph.

Most people think: "Ah well, one update per week is perfectly
sufficient". Which is right from a pure user perspective. But if you
integrate tightly with OSM, imagine what would be possible - a web site
or app that does routing and says: "Found a problem in this route? Fix
the data in OSM and re-try!"

Not saying that you must solve that but if you're looking for unexplored
terrain, here's your change to earn a badge ;)

> Obviously, open toolsets for all this already exist for OSM (I’m aware of at least OSRM and Graphhopper and can find my way slowly around the wiki).

There's also osm2pgrouting which prepares OSM data specifically for the
pgrouting PostgreSQL plugin, and a non-open but free-of-charge solution
called osm2po. Then there's gosmore and Navit, the grandfathers of all
OSM routing engines, and Routino. On the mobile side there's libosmscout
which I believe can do routing, Monav which might be dead, and there's a
specific cycle routing engine called brouter.

You say that you prefer to work geographially rather than topologically.
Again that may make sense from the user viewpoint (although I might be
devious and add a node in a street just under a node in the road that
leads above it on a bridge...) but as a mapper of course I *want*
routing to fail if roads are not properly connected, because only then
will people notice the bug and fix it!

The various routing systems that work with OSM are slow to converge on
common standards - i.e. which tag combination will make a road
accessible for which types of vehicle, what standard speeds should be
assumed for which roads, and so on. That's because everyone extracts and
weighs the routing graph with their own methods (or makes everything
configurable even). If a common standard were to emerge, quality would
likely improve. Alas, it's unlikely that everyone would throw away their
own code and start relying on your standard - unless it is really much
better than what everyone has already.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"