dennis.luxen at gmail.com
Sun Mar 17 08:38:55 UTC 2013
> Supporting OpenLR in OSRM, or adopting some of it's techniques, might
> have several interesting benefits:
> - Supporting roadworks and other types of traffic messages when
> preprocessing data.
This is an idea to consider for the future, but OpenLR needs the maps to
be of equal quality.
> - When using OSRM for GPS turn-by-turn navigation on mobile devices,
> recalculting the route should start from the way you're actually on. If
> you're on a way that's split into two oneway (like a motorway), a small
> GPS error can easily place the starting point in the wrong direction. To
> solve this, OSRM could take into account the direction you're currently
> moving, and perhaps the speed (and thus road class). This is similar to
> how OpenLR works - using bearing, functional road class, etc. to find
> the correct way.
I don't think that this is the right application of OpenLR. The way to
solve this is to select a number of locations close to source and target
and do a proper initalization of source and target search.
> - OSRM could potentially form the basis of a powerful map
> matching/merging tool. For example, in Denmark a lot of road data from
> municipalities was recently released to the public, and people
> (including me) are trying to figure out how to compare and merge it into
> OSM (see http://streetmerge.org). The idea would be to take two maps and
> identify what ways are in one map, but not the other. A purely geometric
> matching is not so effective, due to the differences in how the networks
> are modelled. The OpenLR approach of matching ways would be much better.
> Since OpenLR is based on shortest path routing, OSRM already provides
> half the implementation.
"Doing the first 90% is easy. Doing the other 90% is much harder." ;-)
More information about the OSRM-talk