[OSM-dev] webservice to collect traffic messages

[marcus.wolschon at googlemail.com]

On Mon, 20 Apr 2009 07:56:13 -0400, Greg Troxel <gdt at ir.bbn.com> wrote:
> <marcus.wolschon at googlemail.com> writes:
> 
>> I'd like to experiment with Google AppEngine for a bit and
>> set up a hosted service to collect traffic messages
>> (traffic jams, road obstructions, constructions sites, slow
>> moving traffic,...)
> 
> I'm not sure how you're intending to use this, but I'm guessing peer
...

Actually it's just going to be a proof of concept.
If the format as well as my atempt to get input from
the other developers of the other navigators work out
I am thinking about having some fun with car2car.
For that traffic messages in a general format would be
a good starting point and then there are lots of fun things
you can do with map-updates and communication while driving
in a convoy.

At the moment I get lots of traffic messages from TMC but
I don't want to hardcode a specific source of such information.
Keep it open for others with good ideas.

> Have you looked at the format specs for TMC:
> 
>   http://en.wikipedia.org/wiki/Traffic_Message_Channel
> 
> It's not the least bit clear that it's the right thing, but probably
> worth glancing at.

Well, I am programming on the TMC LocationCodeList-import for
Germany (Roads work, Segments are difficult, Points get scary),
did the TMC-implementation in Traveling Salesman and have the
ISO-documents on it next to me. 
..too late, I already glanced. ;)

>> What could be a good data-format for such information, so that
>> it is usefull to more then just my own navigator?
>> I'm thinking about:
>> * required: (enum) event-type
>> * required: (string) event-description
>> * required: (long) OSM WayID of primary location
>> * required: (long) OSM NodeID of primary location
> 
> Not sure what you mean by long, but protocols should only use
> fixed-width types, so perhaps uint32_t, or perhaps uint64_t to avoid
> having to change the protocol when there are more than 4G nodes.  Or
> perhaps this is xml so it's just a number.

long=signed 64bit integer. The datatype osmosis uses for IDs
and thus the one I inherited for all my code.

>> * required: (datatime) expiration date of the event
> 
> I don't follow this - I would expect a time of report, and perhaps an
> expected time remaining.

time of report + expected duration = expiration time.

>> * optional: (long[]) additional affected nodeIDs
>> * optional: (long[]) additional affected wayIDs
> 
>> * optional: (time) expected delay
> 
> Presumably this is the number of seconds that travel would take minus
> the number it would take under normal time?

I was thinking about milliseconds as that is the natural
unit of time but yes. In TMC I sometimes get this in minutes,
sometimes I get a length of a traffic jam and can aproximate
this.

>> * optional: (string[]) additionalData
> 
> for humans?

For future extensions. Never design a protocoll without either
a version number or fields reserved for extending it.

>> Are OSM nodeIDs and wayIDs a usefull reference for other (OSM-)
>> applications
>> or shall I add required lat + lon + ref/name -attributes?
> 
> With OSM ids, one can only generate and use data if one has OSM data
> locally, and then only if it's the same version - what if there was an
> edit to add/remove ways that didn't really change the map massively
> semantically, but changed way ids?

I find it very hard to map things line "road-name"+"lat"+"lon"
to a way efficiently and correctly. That's why I am asking for better
options.

> This data could be useful to display without the detailed database.
> 
> It would be nice to have this data be useful over long time scales,
> looking at the frequency of (reported) trouble.  So using way ids as the
> primary key seems like it could be trouble.
> 
> I would expect that routing applications have to figure out from
> position where one is anyway, so reporting by lat/lon makes sense.
> Except in very messy areas with lots of stacked ramps.

Take a simple dual-carriageway or the usual case that a traffic jam is
reported to start at a motorway-crossing. There are lots of ways.

> So perhaps lat/lon, and an optional way id for disambiguation, but which
> can be ignored if it doesn't make sense.

Lat+Lon+direction of moving traffic could be more stable if the nodes
get moved around.

Marcus