[Routing] Crowdsourced costing
Nic Roets
nroets at gmail.com
Tue Dec 2 21:37:12 GMT 2008
Of the 3 ideas I'm most inclined to agree with Frederik. From the
discussions on talk regarding smoothness and the slowdown in user edits,
it's clear that the community is willing to fine tune all supported routing
tags, provided it's easy and (nearly) interactive:
* 1 numeric parameter per way for each vehicle type.
* Allow hundreds of vehicle types. Anything from a courier delivering
documents to a tourist on a mountain bike taking the scenic route. Anyone
who disagrees with your (subjective) tagging, should just add their own
vehicle type.
On Tue, Dec 2, 2008 at 9:34 PM, Brandon Martin-Anderson
<badhill at gmail.com>wrote:
> I agree,
>
> My idea for that is: offer draggable routing. When the user drags the
> route off of the original, that is an implicit downvote for all roads
> avoided. That data can be used to increment the weight of the avoided
> roads, or future users can be informed when some statistically
> significant portions of users prefer to avoid their route.
>
> -B
>
> On Tue, Dec 2, 2008 at 10:42 AM, Frederik Ramm <frederik at remote.org>
> wrote:
> > Hi,
> >
> > all of us involved in routing are probably using more or less clever
> > algorithms to compute the "cost" for traveling along a given road. My
> > own experiements which focused on long-distance routing were quite
> > simple and simply assigned an expected speed to each highway type.
> >
> > However, this will only ever make us "as good as" existing routing
> > solutions based on proprierary data: we will never become "better" than
> > them (except perhaps the odd detail in our data that they haven't got).
> >
> > What we should really aim for is to crowd-source the costing, i.e. to
> > give mappers/users control of how likely a certain road will be selected
> > for routing, and how high the penalty is for choosing to route across a
> > given junction (at a given time of day with a given vehicle). There are
> > so many things that locals know ("I would never choose that road on a
> > Tuesday morning because you're more than likely to be stuck behind the
> > garbage collection truck", or "that motorway is only 2% longer but much
> > less likely to have snow", or simply "this is a primary road but the
> > secondary that runs almost in parallel is usually quicker" and so on.
> >
> > There's still some way to go until we achieve this. Perhaps we need to
> > have a separate tagging scheme or maybe even a separate data base for
> > such information, because it is perhaps a bit more volatile than
> > standard OSM data, and it is also quite likely that those that collect
> > costing data are different from those collecting road geometries. But we
> > should really aim for this - a data base where every road has some
> > user-assigned cost would be ideal for routing, and computing the cost
> > based on heuristics is always second-rate.
> >
> > Bye
> > Frederik
> >
> > --
> > Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
> >
> > _______________________________________________
> > Routing mailing list
> > Routing at openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/routing
> >
>
> _______________________________________________
> Routing mailing list
> Routing at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/routing
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/routing/attachments/20081202/5db03d51/attachment.html>
More information about the Routing
mailing list