[OSM-dev] webservice to collect traffic messages

Greg Troxel gdt at ir.bbn.com
Mon Apr 20 12:56:13 BST 2009


<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
reports of issues from people running open source in-car navigation,
perhaps to the point that driving below expected speeds might trigger
automatic reports.  I would expect you are thinking cellphone data
service, but car-car 802.11 with Disruption Tolerant Networking is also
very interesting.  Perhaps you could describe your goals and use cases.

I realize only some of the people here fall into the paranoid category,
but such reports,sent more than very occasionally, and perhaps even at
all will cause the paranoid to worry.  (Of course we keep our phones off
too :-).  So it would be nice to give some thought to the privacy issues
of anonymous reports together with avoiding false reports.  This is
definitely hard.

Given the privacy worries, google is a bit scary - not sure what the
policy is on use of hosted apps data for targeting ads...

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.

> 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.

> * 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.

> * 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?

> * optional: (string[]) additionalData

for humans?

> 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?

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.

So perhaps lat/lon, and an optional way id for disambiguation, but which
can be ignored if it doesn't make sense.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20090420/7647afaf/attachment.pgp>


More information about the dev mailing list