> [Autodetect location] > First of all, there's the "High geographical entropy" approach - have you > suddenly moved a lot? if so, where were the start and end points? > geocode'em, do a bounding box search against a db of bus stops, record the > route and time taken. Unfortunately, this relies on somehow sensing which > form of transport was used, and the problem there is that in town, speed > won't do as traffic is often at walking or cycling pace. If we assume they're not cycling (or driving, for that matter) for now, they shouldn't be going much faster than 15 mph* over any sustained distance, or 20 mph** instantaneously. If we see those, we assume they're in a bus or similar. (I assume the GPS will successfully work in a bus in the same way a car's does?) *: fastest marathon average speed **: an 11-second hundred metres. We may be able to rule out cycling and cars if they continue at a high speed which doesn't tally with a known route, or don't have near-zero velocity at a valid start/end point. We could also use whether the bus regularly stops (and potentially use that data, too.)
> Second problem - it also involves a background service checking GPS > locations, which on Android is a sure fire battery killer. This is a major hurdle. > Third problem - anybody got a database of bus stops? Already answered. > Another problem would be ambiguous stops - a lot of bus stops and tube lines > and railway stations are the same place or at least within typical GPS > circular error probable (and doesn't that phrase take you baaack to the cold > war). We might not be able to differentiate between stops, but we can differentiate between lines. Unless, of course, the bus line follows the tram line for the whole journey (not unreasonable.) We can always ask when we ask the user to confirm that a journey has occurred. > Obviously, being prompted as to whether you were about to take a bus every > time you were within 24 metres of a bus stop would be tiresome. You don't need to prompt until they get off, perhaps? > So I think user-declared data is probably > the way to go. Tweets are one option, an SMS shortcode is another (although, > in some ways twitter-by-SMS replicates a lot of the functionality). Users remembering to submit data is likely to have a significant sampling bias: 'oh, the bus was really slow yesterday, I should measure it today.' > Hmm, what about the Oyster account web interface? There can be no objection > to screenscraping your own account. Of course that creates a systematic bias > towards postpaid Oyster users which may or may not be significant. > [also, pay by phone] This is probably less bias than 'has a GPS-sensing phone and got the app' will introduce. _______________________________________________ Mailing list [email protected] Archive, settings, or unsubscribe: https://secure.mysociety.org/admin/lists/mailman/listinfo/developers-public
