[OSM-dev] webservice to collect traffic messages
marcus.wolschon at googlemail.com
marcus.wolschon at googlemail.com
Mon Apr 20 13:13:01 BST 2009
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:
> 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
>> * 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-)
>> 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
> 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.
More information about the dev