[OSM-dev] [Routing] webservice to collect traffic messages

[marcus.wolschon at googlemail.com]

On Tue, 21 Apr 2009 09:17:36 +0100, Tom Evans <tom_evans_a at yahoo.co.uk>
wrote:
> marcus.wolschon at 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