SCORE Project: Rider Track
Title: Event Rider/Hiker Tracking
Sponsor: Michal Young
Some longer athletic events, such as ultra-marathon foot races and grand randonnée bicycle events, provide tracking of participant progress. At the very least, they typically publish a table reporting the last checkpoint a runner or rider has passed. In addition, some provide more fine-grain tracking GPS tracking through services like TrackLeaders.com and Maprogress.com. In addition to dedicated satellite tracking devices produced by Spot (findmespot.com) and Delorme (now part of Garmin), increasingly individual GPS receiver devices pair with mobile phones to transmit real-time location data, and stand-alone mobile phone applications can likewise transmit real-time location data. I would like a flexible, extensible system to integrate tracking data from multiple sources (e.g., FindMeSpot trackers, Garmin InReach trackers, mobile phone apps, and future sources that haven’t been introduced yet). It should provide at least a responsive web interface that works well on both small-screen devices (at least as small as a typical mobile phone) and on larger screen devices (laptops and desktop computers, or ‘screencasts’ from a mobile device to a television screen). Additional interfaces, such as dedicated mobile phone apps, would be desirable if (but only if) they significantly improve on the user interface of a web app.
Product Requirements
The key distinction between this tracking application and prior services is in support of multiple forms of tracking input, including those that do not yet exist. For example, competitive marathoners do not currently wear tracking devices (aside from tiny timing chips attached to their shoes) because current devices are too heavy, but this may change in the future. More phone-based sources of tracking data for cyclist and hikers are certain to be introduced. The tracking application must be thought of as a first in a line of products that will accept more sources of tracking input over time. Thus the interfaces provided to future developers are as important as the interfaces provided to end users. These interfaces must be clean, general, and well-documented. It would be particularly useful to treat one or more of the initial input source modules as an example to be followed by developers of other input source modules.
End User Requirements
Product requirements from an end-user perspective are broken out by the roles end users may play. Some of these roles might be played by the same person (e.g., an event administrator might or might not also be the person who installs a tracking service on a suitable server).
Administrative user (installer): The administrative user needs clear documentation for downloading and installing the tracker. This might involve installation on a cloud service (AWS, Heroku, Digital Ocean, etc) or on a shared server.
Event administrator: An event administrator plans and manages an event. The event administrator must be able to create an event, associate it with a route (or possibly multiple alternative routes), open the event for participant registration, activate tracking at the beginning of the event, deactivate it at the end, and eventually delete or archive an event.
Event participant: An event participant must be able to convey information required for tracking (e.g., a device identifier for current satellite tracking devices) and possibly check in along the event route. An event participant should receive a link that they can share with spectators who may be interested in tracking their progress in the event.
Event spectator: An event spectator should be able to follow an individual participant or all participants through some map-based display that shows progress along the route. Available data should at a minimum include freshness of the track data, i.e., the time of the most recent track data from each participant. Additional data may be displayed. Optionally, displayed data may be categorized as private (displayed only to spectators with a link for following a particular participant) and public (available to all spectators watching the event). For example, some current satellite trackers include custom message facilities, which participants might prefer to share selectively.
Project Requirements
In addition to features visible to end users, the project must meet some additional requirements to be suitable as the basis for an extensible family of event trackers.
The code base and documentation must be offered under an open source license and available through a widely accessible repository such as GitHub or BitBucket.
To the extent practical, the project should be built on open source and widely available platforms and components which minimize the barrier to adoption by future developers. The benefits and costs of external dependencies should be carefully weighed, and dependencies should be justified. (For example, adoption of a particular database system is an external dependency which may be justified but has some cost to future developers as well as end users.)
The project must be well organized and appropriately documented for future developers. A potential developer should be able to quickly determine how to add a new input source. As noted above, treating at least one input source as a model for future input modules is a particularly effective approach to documentation. Other variations and potential extensions of the system should be considered as well.
Stakeholder Interaction
Project teams are encouraged to communicate with the sponsor at all stages in the project, including consideration of product features and provided APIs. Professor Young has been both a participant and an event organizer for randonneuring events, and can provide a first-hand perspective on end-user needs for tracking bicycle events. Teams are encouraged, however, to consider also other kinds of long distance events and to interact with organizers and participants in events such as long hikes and ultra-marathon foot races. A product focused on the needs of hikers, for example, would be as welcome as one focused on the needs of randonneurs.
Sponsor contact: michal (at) cs (dot) utexas (dot) edu
Project Restrictions
None.
Project FAQ
Answers to selected questions will appear here.