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

marcus.wolschon at googlemail.com marcus.wolschon at googlemail.com
Tue Apr 21 06:51:12 BST 2009


On Mon, 20 Apr 2009 18:46:38 +0200, Doru Julian Bugariu <j.bugariu at wad.org>
wrote:
> marcus.wolschon at googlemail.com schrieb:
> 
>> I'm thinking about:
> 
> + Use a cool name: "OTM" OpenTrafficMessages
> + Version of protocol
> 
>> * required: (enum) event-type
>> * required: (string) event-description
> 
> Isn't that redundant to event-type?

No. An event-type can only encode a very short list of
events like "traffic jam|roadblock|slow|other" but
the description can be human readable and contain that
it is a "traffic jam due to lost cargo".

>> * required: (long) OSM WayID of primary location
>> * required: (long) OSM NodeID of primary location
> 
> Why not use dedicated tags and IDs for it? They even may be attached
> automatically to existing ways by a bot.

Because then only location with these tags can have a traffic
message. That would work for TMC-messages but not for others.

>> * required: (datatime) expiration date of the event
> 
> Why not starting time and duration?

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.

>> * optional: (long[]) additional affected nodeIDs
>> * optional: (long[]) additional affected wayIDs
> 
> Good idea.
> 
>> * optional: (time) expected delay
> 
> Delay if going through "specified event"?

Yes, I like to make it as easy as possible to use
the service. It it gets too complicated (like every developer
having to figure out a way to calculate how fast you can move
in a given traffic jam) noonw will implement clients.

>> * optional: (string[]) additionalData
> 
>> Are OSM nodeIDs and wayIDs a usefull reference for other (OSM-)
>> applications
>> or shall I add required lat + lon + ref/name -attributes?
> 
> Node IDs and Way IDs may change through time. Lon + Lat + Ref/Name may
> be hard to code and error-prone.

NodeIDs and WayIDs are stable enough for any even that lasts only a few
hours anyway but for long lasting events and for clients that did not
preserve the entity-IDs or are simply not using the OSM as a map
I'll add lat+lon+direction of at least the primary location. That should
also eleminate the issue Floris and you pointed out with entity-IDs
changing.

Marcus




More information about the dev mailing list