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

Marcus Wolschon Marcus at Wolschon.biz
Wed Dec 3 06:50:26 GMT 2008


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.




More information about the Routing mailing list