Wiki

Breadcrumb

Brief Hardware Requirement: This application would make use of a handsets GPS module along with network connectivity.

Brief Overview: Allows a user in an unfamiliar physical environment to find their way back to a particular place without having to remember their route. Might be handy for piss heads who end up leaving random house parties @ 6am to find themselves in a housing estate that they have no clue when or how they got there along with how they can get back to more familiar turf. Obviously tourists would benefit from such an application (get back to a meeting spot, etc). To put simply it allows people track their movements and retrace their steps

Brief Design Suggestion: So the application could comprise of a simple GUI interface, starting off with two options. “Start” and “Settings”. When the user presses “Start”, the application will init the GPS module and start receiving location data. The app will then write a session log to the local file system, comprising of a time stamp, a GPS coordinate, and an error code. The time stamp is useful because it will let us infer the sequence of coordinates recorded, so we could literally “Play Back” a journey. E.g. if a tourist wandered all over a city they may very well pass nearby the same locations several times, so this way the app could pinpoint where they were and at what time and in what order their steps were made. The GPS coordinate parameter is self explanatory and the error code will let us know if the GPS module had any problems requesting satellite data for a given sample. E.g. a tourist turns on the app when they get off a bus, and then wanders around for a while entering and leaving buildings. While inside a building the GPS module will probably not be able to get location information. We could go many ways with that, we could keep to a user defined sample rate and include the “satellite not reachable” error code, or just not write a log entry if the data is currently unavailable. The latter would result in variable time gaps between samples logged.

Another fairly important factor for determining a more ideal sample rate for the logging of GPS data would be the speed by which the user is travelling. We cannot assume that the user is travelling by foot, so their speed could vary significantly. In the “Settings” of the application we could have a static sample rate where the user defines the time between samples (typically in seconds). Alternatively we could provide a dynamic option, whereby the average distance between the last (n) points captured could influence a new sample rate. E.g. if I am walking and now I get in to a taxi, then I will be moving much quicker in the taxi and should ideally increase the sample rate of GPS coordinates in order to capture more accurate route information. When walking you're not going to get very far in 20 seconds, but in a car the potential for covering more ground is obviously greater. The reason why we wouldn't just max out the sample rate is because it would most likely require more power from the phone and end up killing it unnecessarily.

Anyway, after the person has pressed “Start” the display could show the number of samples (or steps) captured and the number of failed GPS coordinate captures (or simply a percentage success rate for the current session). At that stage the display will update upon each sample attempt, and the “Start” button will now toggle to a “Stop” button. When “Stop” is pressed, the application will finishing writing/appending to the session log. The option to view/playback your recent session on a visual map will be offered. If selected, the application will start a network/data connection (up until this point no cost in involved) and load a Google Map. From the logged session data you could fairly easily determine boundary coordinates (a rectangular area on a map), which would show the entire area that you traveled within during that session.

With a map now displayed with a zoom level on the map set, that adequately allows you to view the entire area, there are several things we could do here. Google maps has a route finder so you could simply ask that to give you a route from your current location back to the first sampled location. That's handy if the person just wants to get back to where they started, quickly. Alternatively they could play back their entire journey, forwards, backwards, from a particular point, and see what time they were at a particular location. Handy if the have lost something and knew that they had it up until a certain time and want to retrace their steps.

Another spin off application could be, when the user clicks “Stop” the facility to upload the recent session log to a web service or send the log to another application user. E.g. Mates of mine are currently buying a house down in the shticks and I know it's going to be difficult to find their house. They will most likely know the best route to their new dwelling from the city, so on the way they could record their journey and then publish their session log to a web service for friends to download later. A bit like a social network with overlaying groups whereby members of a group can access publishes routes within the group and easily pull them down to their phone and play them back in the application. It would also give someone a more realistic journey times as opposed to relying upon some of those God awful estimates that Google Maps and AA Route planner suggest.

Suggested Licensing Model: GNU General Public License (GPL)

I have some more ideas for different applications, but I put this one forth as something that isn't too big/complex, making it more accessible as a project to get us comfortable with the device. Also feel free to comment on my suggestion below. Likes / Dislikes / Questions / Contributions / etc We agreed in the meeting held last night that we're all still installing / playing around with the Android SDK and development tools and not yet ready to just start developing a project. So while everyone is getting their heads around Java / Eclipse / Android SDK / etc, we could focus on evolving the application concept in to something more formal (a requirement spec.) before we design/implement anything. That way everyone will be happy with at least the initial feature set and have the time to share technical knowledge that would enable more people get involved. IMO it's only after we have a “design” we can start delegating work packages to individual contributors with a well defined integration plan. That way people won't end up stepping on other people's toes or producing redundant code.

breadcrumbs_app.txt · Last modified: 2010/09/09 15:44 by carles