Hi! We see you’re using an ad-blocker. We’re fine with that and won’t stop you visiting the site.
But as we’re losing ad-revenue from this then why not make a donation towards website running costs?. Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!
Posted: Wed May 11, 2005 3:10 pm Post subject: "Collaborative TMC" proposal
TMC services are sometimes untimely and, perhaps most importantly, they're usually not very fine-grained: for example, they don't give any traffic information for streets inside (most?) cities.
Here is an idea: what if every GPS user sent traffic data to a central server that anybody could access?
Your GPS knows your car's speed. While that speed is also related to (duh) how fast you go, I believe the average speed detected by the average GPS will be quite strongly related to the current traffic volume.
Now imagine that you have a program on your PDA, alongside your normal navigation software, which periodically uploads your speed and location to some server, via GPRS. If the software were smart enough and enough users chose to install it, I think valuable traffic data could be collected.
If you don't have GPRS, you could always upload your data afterwards by syncing the PDA to your desktop - sure, this way the data would come a little late, but it's still better than nothing and, if nothing else, these data could be used to collect average traffic data for specific times of the day and days of the week.
The best way to engineer the software would be, in my opinion, to have a program acting similar to GpsGate, i.e. intercepting GPS (NMEA) data before they reach the navigation software, in order to
1) collect the necessary data to upload to the central server
2) download the central server's data and "fake" TMC-compliant data for the navigation software to interpret
This way, navigation software could read traffic data itself and route you accordingly, as if it were real TMC, without the user having to look at an additional program.
I see a problem here, though, as I believe that real TMC data are sent according to a database of roads that is replicated in TMC-aware navigation software. If this is the case, then navigation software would not know about city streets and other minor roads; but perhaps this can be solved, or maybe it's a non-issue (since I currently know very little about the TMC protocol).
The central server's software would need to have a world-wide map available in order to translate user-uploaded coordinates into *roads*, which is needed to create TMC-compatible data.
This is a problem, since there is no freely available detailed map data that I know of; however, these maps would not need to include everything there is in NavTeq's or TeleAtlas maps: only streets and their names are necessary.
Maybe VMAP1 data will be released sooner or later, or maybe another approach could be taken, but in any case, I don't think this would necessarily be a show-stopper.
Lastly, some hypothetical users of this hypothetical system could be concerned about privacy. However, I'm sure the data sent could be made anonymous enough (and features like "don't send speeds that are over the speed limit" could be added to the software, for the Real Paranoid People ;-). In addition, if everything were open-source (which is IMHO the only viable possibility), user trust would probably be quite high.
I'd like to know what people think of this idea. Also, if anybody has some good pointers to a) TMC protocol specs, b) serial port management in Windows CE, c) creating a virtual serial port in Windows CE, they are very welcome.
Joined: 02/11/2002 22:41:59 Posts: 11878 Location: Massachusetts, USA
Posted: Wed May 11, 2005 9:12 pm Post subject:
Let's talk about TomTom. The maps contain TMC codes - identifiers for pieces of highways, intersections, etc. So you could map your current location back to a TMC code, and then report the issue.
The problem with reporting the issue is cost and incentive. Reporting is not free (GPRS transmission costs), and you can only hope that one day you will benefit from the message someone else has submitted. I admit there is an element of "15 minutes of fame" which could be used to the advantage of the project - like "This accident information brought to you by James Miller".
Eventually you need to ask - why TMC? Why not simply use lon/lat coordinates or polygons (pieces of streets instead of singular points). That way also programs that don't know about TMC could benefit from that.
Let's talk about TomTom. The maps contain TMC codes - identifiers for pieces of highways, intersections, etc. So you could map your current location back to a TMC code, and then report the issue.
Yep. However, TMC codes only exist for major roads, and this would be a problem. The main usefulness of this idea, in my opinion, would be for cities.
So we'd need to create a "custom" TMC database to complement the published national standards... however, it remains to be seen wether TomTom and company somehow allow tweaking their TMC database.
Quote:
The problem with reporting the issue is cost and incentive. Reporting is not free (GPRS transmission costs), and you can only hope that one day you will benefit from the message someone else has submitted.
But my idea is this: the system would be free to use, *but* you'd *have to* submit your current location's traffic data in order to receive data in exchange.
Then you could fake the data if you really wanted to, but that wouldn't help you to save GPRS costs.
Anyway, I think the size of the data you'd have to *send* could be quite modest in comparison with the traffic data you'd *receive* if the system worked well.
Example: say you set up your program to update the traffic situation every 10 minutes. Every 10 minutes, you'd receive traffic information about many streets near you, and you'd only have to send something like "longitude latitude speed" or "TMC-marker speed".
And if you don't have GPRS (I don't have GPRS), all you'd have to do is sync your PDA when you come back home. How relevant your data would then be depends on how long your journey was; however, for city driving, this model should still provide valuable data.
The other way round would work similarly: if you don't have GPRS, you sync your PDA before driving, in order to get traffic info that are accurate at least for the next hour or so (talking about traffic volume of course, not accidents).
Quote:
I admit there is an element of "15 minutes of fame" which could be used to the advantage of the project - like "This accident information brought to you by James Miller".
I actually hadn't thought of this, but it could be one incentive more.
Actually, it probably could be an incentive for people to *report* traffic "anomalities" -- the system as I envisioned it would not be able to alert of a complete traffic stop (like an accident), it could only tell people "look, in place X people are going at speed Y on average".
But maybe the "15 minutes of fame" could make people willing to click on an "Accident" button on their PDA?
Quote:
Eventually you need to ask - why TMC? Why not simply use lon/lat coordinates or polygons (pieces of streets instead of singular points).
That way also programs that don't know about TMC could benefit from that.
Well, TMC-formatted data are useful because many navigation programs can interpret them directly and create route diversions based on them.
In addition, if you have TMC data (and the corresponding database...), coordinates can be obtained from them as well.
As we said, though, using TMC definitely does pose problems, so perhaps using coordinates or polygons is better. We'd lose "seamless compatibility" with TMC-aware programs, but TomTom and most of the other offer SDK's, so people could probably write plug-ins.
As you can see, you get the average travelling speed for every monitored stretch of road (and also accident spots with the Paris system).
So what I thought was, why not have something like that using GPS instead of all the sensors? If everyone who wants to *receive* traffic information also *sends* their location's data, IMHO it could work.
One word of caution - what you are trying to achieve was once part of Mapopolis. They called it Clearroute, and it worked very good. However, they had to discontinue the service because nobody wanted to pay for it. Maybe they were too far ahead of their time - who knows.
What I'm saying is - don't underestimate the GPRS download costs. This is the biggest contributor to the "business model". Everything else - including the uploads - is just peanuts. _________________ Lutz
Joined: Jun 16, 2004 Posts: 454 Location: London, Ingerlund
Posted: Thu May 12, 2005 9:24 am Post subject:
The kind of system you talk about is already in use, albeit on a slightly smaller scale. ITIS (one of the main traffic information companies in the UK) already do this. They take information from tracked vehicles and process it all (anonymously of course - nobody can actually see where you are) to help them with their traffic info.
Yes, well, you know, in Europe one has to wait for technologies until about when they become obsolete in the US... all I know is that I would really like to see such a system active in my city (Milan, Italy).
Not only to get traffic information, but also to let them tune the darn traffic lights (no wonder Italians invariably run red lights, you'd have to see how they're timed!). Also, to give a green light to trams and buses - it's just plain stupid that trams have to wait for green lights, considering that stops *are at* traffic lights!
Well, fine, I've complained enough.
Quote:
One word of caution - what you are trying to achieve was once part of Mapopolis. They called it Clearroute, and it worked very good. However, they had to discontinue the service because nobody wanted to pay for it. Maybe they were too far ahead of their time - who knows.
Oh. I didn't know. But, was it a subscription service (that is, did you have to pay Mapopolis *in addition to* paying for your GPRS connection)?
Quote:
What I'm saying is - don't underestimate the GPRS download costs. This is the biggest contributor to the "business model". Everything else - including the uploads - is just peanuts.
I see. However, GPRS cost may decrease when and if the service becomes more widely used. In any case, are GPRS costs really so high? If I recall correctly, I pay 0,004€ (0,4 cents) for each kB transfered (for "Internet" transfers, not WAP transfers - those are 0,04€ per kB).
With good compression (where "compression" may simply mean, "use a decently concise protocol") one could surely stuff quite a few traffic data in a couple of cents spent...?
TMC services are sometimes untimely and, perhaps most importantly, they're usually not very fine-grained: for example, they don't give any traffic information for streets inside (most?) cities.
Here is an idea: what if every GPS user sent traffic data to a central server that anybody could access?
Your GPS knows your car's speed. While that speed is also related to (duh) how fast you go, I believe the average speed detected by the average GPS will be quite strongly related to the current traffic volume.
Now imagine that you have a program on your PDA, alongside your normal navigation software, which periodically uploads your speed and location to some server, via GPRS. If the software were smart enough and enough users chose to install it, I think valuable traffic data could be collected.
If you don't have GPRS, you could always upload your data afterwards by syncing the PDA to your desktop - sure, this way the data would come a little late, but it's still better than nothing and, if nothing else, these data could be used to collect average traffic data for specific times of the day and days of the week.
The best way to engineer the software would be, in my opinion, to have a program acting similar to GpsGate, i.e. intercepting GPS (NMEA) data before they reach the navigation software, in order to
1) collect the necessary data to upload to the central server
2) download the central server's data and "fake" TMC-compliant data for the navigation software to interpret
This way, navigation software could read traffic data itself and route you accordingly, as if it were real TMC, without the user having to look at an additional program.
I see a problem here, though, as I believe that real TMC data are sent according to a database of roads that is replicated in TMC-aware navigation software. If this is the case, then navigation software would not know about city streets and other minor roads; but perhaps this can be solved, or maybe it's a non-issue (since I currently know very little about the TMC protocol).
The central server's software would need to have a world-wide map available in order to translate user-uploaded coordinates into *roads*, which is needed to create TMC-compatible data.
This is a problem, since there is no freely available detailed map data that I know of; however, these maps would not need to include everything there is in NavTeq's or TeleAtlas maps: only streets and their names are necessary.
Maybe VMAP1 data will be released sooner or later, or maybe another approach could be taken, but in any case, I don't think this would necessarily be a show-stopper.
Lastly, some hypothetical users of this hypothetical system could be concerned about privacy. However, I'm sure the data sent could be made anonymous enough (and features like "don't send speeds that are over the speed limit" could be added to the software, for the Real Paranoid People ;-). In addition, if everything were open-source (which is IMHO the only viable possibility), user trust would probably be quite high.
I'd like to know what people think of this idea. Also, if anybody has some good pointers to a) TMC protocol specs, b) serial port management in Windows CE, c) creating a virtual serial port in Windows CE, they are very welcome.
Posted: Today Post subject: Pocket GPS Advertising
We see you’re using an ad-blocker. We’re fine with that and won’t stop you visiting the site.
Have you considered making a donation towards website running costs?. Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!
Hi! We see you’re using an ad-blocker. We’re fine with that and won’t stop you visiting the site.
But as we’re losing ad-revenue from this then why not make a donation towards website running costs?. Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!
Forum FAQ
Search
Usergroups
Profile
Log in for private messages
Log in
