On Tue, 21 Apr 2009 09:17:36 +0100, Tom Evans <tom_evan...@yahoo.co.uk> wrote: > marcus.wolsc...@googlemail.com wrote: >> Why would anyone be interested in when the event started? >> It's there, it will be there when you get there so it's >> to be used in the metric. > > Most traffic congestion doesn't operate to an accurate timetable? > Typically, you have observations of the congestion (at a known > time), and an estimated (i.e. made up) duration.
Correct and if a new estimate becomes known or the cancellation of the event is broadcast it gets updated. > For the few events which are predictable, you'd want to take > advantage of that and broadcast the prediction. But without implying > the event has already started. Unless I'm missing something, you > can't do that with just expiration date. Just a thought. So you mean expected events? I did not think about these before. Do you know any sources where we may actually get such data? This is becoming more complicated then I expected. What about: # eventid (generated) # source-system (wenn known constants such as "TMC", "UserInput", "FloatingCar"...) # reported/updated by (list of accountIDs) # event-type (few, well known constants) # event-description (human readable) # valid-until # valid-from # primary location * lat, lon * if known: ref/name * either nodeID+wayID (point) or relationID(area) # direction (compass-degrees) # list secondary locations # list of additional name->value -pairs (+wiki describng the ones used) You can then query all current messages by: * a bounding-box * + version-number of the protocol used * + list of understood keys for the additional data (or "*" for all). * + optional flag to not include the secondary locations Messages can be updated given their id. Expired messages get removed. You have to register a user-account but need not give personal information. (So sources of bogus messages can be tracked.) The client-application is responsible for choosing what messages from what sources to trust. Examples of area-locations are meteorological conditions. The event-type shall be few and represent the expected action to be taken rather then the exact nature of the event. examples for additional name->value pairs would be: * length of a traffic jam in meters * original TMC-message+CID/TABCD in hexadecimal Marcus _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev