<[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 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.
pgptTpNlEQ6rq.pgp
Description: PGP signature
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
