On Mon, 20 Apr 2009 07:56:13 -0400, Greg Troxel <[email protected]> wrote: > <[email protected]> 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 _______________________________________________ Routing mailing list [email protected] http://lists.openstreetmap.org/listinfo/routing
