[Routing] Crowdsourced costing - offer of writing a client+metric for it

[Jaak Laineste]

Hi,

 Wouldn't it be too complicated to have proper coverage? Some of the data,
like average speed, is also very hard easy to estimate without really good
experiences or specialist analysis. And average speed is most important data
for fastest way calculation, it would be too easy to get garbage-in
garbage-out situation.

 I would suggest to have live traffic event data, collectable mostly using
mobile devices from the road. The events could be:
a) road temporarily blocked. No routing over here.
b) road speed disturbance (e.g. traffic jam). Calculate extra time for
routing.
c) other traffic-related events: e.g. mobile speed trap. Notify user,
perhaps does not affect routing.

With mobile data collection it should be very easy, possible to be entered
while driving (click "mark traffic event to current location", select type
from short list, OK), so any extra data (like estimated duration of event)
should be optional. Maybe for block duration is essential: it could be 3
month roadworks, or just 30 minutes due to an accident.

 Technically, the "mark" event is then attached to certain road segment,
which is found automatically from user's current GPS location.

 This is actually also something what some commercial providers have now
also, some Tomtom devices can collect this kind of data from crowd also, and
share with fellow tomtom users, but OSM database would be much more open and
with wider coverage.

/Jaak

-----Original Message-----
From: routing-bounces at openstreetmap.org
[mailto:routing-bounces at openstreetmap.org] On Behalf Of Marcus Wolschon
Sent: 3. detsember 2008. a. 8:50
To: routing at openstreetmap.org
Subject: Re: [Routing] Crowdsourced costing - offer of writing a
client+metric for it


Hello,

I suggest a service that collects the following data:

collection:
* vehicly-category (car,bike,foot,ship,other)
* vehicle-type (String, freely chosen with some presets)
** vehicly-subtype (flow, normal, fast)
** used metric (String, freely chosen, presets: fastest, shortest,
efficient, scenic, mapping)
* average speed in km/h
* way-ID, startNode, endNode
* day = (weekday,weekend,holiday)
* time = (night,morning,afternoon)
** sub-time = (early,mid,late)

example: car-fast, 123-456 on way 789 with 78km/h at early morning

privacy: 
* the user-application is supposed to care about not sending
  information about a user-chosen radius around the start and end of a
route
* we do not receive exact times or dates because there is no need to care
  about them anyway
* we do not receive user-identifications at all
* the IP and upload-time are stored to revert manually detected vandalism

retrieval:
* the service can be asked with the same query-parameters that collection
has
* if a significant number of exact matches exist, they are returned
* if not it uses data for other streets of this highway-value, other
vehicly-types,...
  and multiplies the difference 
  e.g. (average for noon everywhere)/(average of all times everywhere) as
an offset
  to give better estimates where it has no exact data.

This can be hosted as a web-service with SOAP and a WSDL to be usable for
pretty much all programming-languages and platforms. The data would not be
stored in the OSM-database at all but in a separate database.

A prototype can be written e.g. in google-app-engine to gather
real-world-experience
with this kind of service.
I am offering to implement a well documented client and a metric for such a
service as a plugin into my own navigation-software Traveling Salesman as a
testbed and reference-implementation.

I am currently busy debugging my osmbin indexed, mutable, binary
file-format for
osm-data. So I do not know if I can find the time to write such a service
myself
in the next weeks but I sure would like to. 

Marcus


On Tue, 2 Dec 2008 23:37:12 +0200, "Nic Roets" <nroets at gmail.com> wrote:
> 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.

_______________________________________________
Routing mailing list
Routing at openstreetmap.org
http://lists.openstreetmap.org/listinfo/routing