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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marcus Wolschon Sent: 3. detsember 2008. a. 8:50 To: [email protected] 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" <[EMAIL PROTECTED]> 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 [email protected] http://lists.openstreetmap.org/listinfo/routing _______________________________________________ Routing mailing list [email protected] http://lists.openstreetmap.org/listinfo/routing
