This won't work like Seth wants. The problem is the following:
- Few users have the iPhone hooked up to a car charger when in their cars.
- The GPS receiver sucks up power like mad when it's on. A constant connection will drain the battery very quickly.
- The iPhone is also incapable of passively uploading GPS data to a remote source, nor is it capable of running an app in the background. This is to say, your users must keep their iPhone unlocked (disabling auto-sleep) and your app open at all times. This is similarly a large drain on your battery.
The amount of work (buying a car charger, making sure to hook it up, unlock the phone, and open your app, and disable auto-lock) every time the user needs to use the service is just absurd. This has no chance of working as it is.
It's a cool idea, and if we all had devices in our pockets that can, without excessive hackery, sustain a continuous GPS feed to a 3rd-party source, this would actually work. Sadly, the iPhone is not it.
> sustain a continuous GPS feed to a 3rd-party source
Is that even a requirement? Can't you just sync every 5 minutes or so? Or sync more often when the battery is full, and sync less often when the battery is starting to deplete - given enough users that should take care of the power issue. Because it doesn't take a lot of energy to download the congestion information, so like with Bittorrent you only need a couple of seeders.
Bear in mind that you need only one data point to prove there is no congestion: a single car driving at 70 miles/hr rules out congestion at that road.
I expect it will work if all taxis are seeders, and all commuters are leeching. Considering taxis benefit a lot from such a service it's not unrealistic.
The auto-locking problem is another technical nuisance. A firmware update would fix that.
Also, I think the problem should be solved entirely without GPS. You don't want a machine to tell you that traffic is OK, what you really want is to receive a text message whenever there are traffic problems on your usual route on weekdays. "Traffic jam at intersection X" is all you need. When you get that message you just have to take a minute to figure out alternative route. The passive approach is much more appealing. After all, if traffic has been good all week you're not going to check your iPhone the next morning. Just not worth the trouble.
You could do every 5 minutes - but that would still be impossible on the iPhone, where your phone would have to remain unlocked (i.e. screen on) and your app open the entire time to do so. That is perhaps a bigger battery hog than the GPS receiver itself.
Also bear in mind that position acquisition is far from instantaneous, and has a high fixed cost. 5 minutes is probably ok, but keep in mind that your receiver is puttering away for a good minute before your scheduled check-in, just so your GPS can reacquire its position.
This would work if the software was integrated into a GPS unit, but not a cell phone. Taxi drivers in particular always have their GPS units chained to a car charger source, and this eliminates your power issue. Further, a GPS unit doesn't need to be hacked to support background applications :)
I think you misunderstand the intent of the idea - which is to use other people stuck in traffic jams to warn others who are approaching to divert. This absolutely requires a GPS unit of some sort. The data in this model is emergent, as opposed to human processed (e.g. a driver calling in an accident at an intersection).
Thanks! Something running s60 is interesting to me since it seems like it would be easier to program. My current phone is a treo 650 (palm), and I am disappointed at how high the barrier to programming it is.
I have spoken to a member of google maps mobile team (they program for all platforms) and asked him how blackberry compares in difficulty to android or windows. He said that blackaberry is pretty bad, but the most painful ever is Symbian. 2 cents here.
Interesting. My goals are to write home automation and GPS tracking apps, ideally in python. Stuff like that open-garage-door-when-phone-gets-home project. Any UI work would be web pages, so I guess I want a good web browser.
I'd suspect that problems with implementing gmaps wouldn't affect me. My issues are more like "can I code and deploy from linux?" and "do I get access to the camera, network, speaker, etc?"
- Few users have the iPhone hooked up to a car charger when in their cars.
- The GPS receiver sucks up power like mad when it's on. A constant connection will drain the battery very quickly.
- The iPhone is also incapable of passively uploading GPS data to a remote source, nor is it capable of running an app in the background. This is to say, your users must keep their iPhone unlocked (disabling auto-sleep) and your app open at all times. This is similarly a large drain on your battery.
The amount of work (buying a car charger, making sure to hook it up, unlock the phone, and open your app, and disable auto-lock) every time the user needs to use the service is just absurd. This has no chance of working as it is.
It's a cool idea, and if we all had devices in our pockets that can, without excessive hackery, sustain a continuous GPS feed to a 3rd-party source, this would actually work. Sadly, the iPhone is not it.