Route editor

This document discusses the design for the route editor feature (original by ncjones)

Use Cases

As a user without a GPS device, I want to calculate my activity distance by manually plotting a route.

Additional Requirements

To help me achieve the primary use case, I expect to also be able to:

1. Specify the route while creating the record
2. Save a route and easily reuse it when creating new records
3. Separately manage routes so they can be renamed, modified and deleted.
4. Create routes from a GPS-recorded activity's track points.

Approach

The route graph can be considered an alternative input method for specifying the distance of an activity. As such, only one or the other should be provided by the user; they are mutually exclusive.

The existing "add entry" dialog is very cluttered and the only place a route editor widget could fit currently is on a new tab. Because distance and route are mutually exclusive, it is sensible that they appear next to each other in the UI. This means they would both need to appear on a new tab for providing distance.

However, since distance, along with duration, are the two most important pieces of information being provided for an activity, moving them to a new tab would severely detract from the usability of the "add entry" functionality. A better approach is to rework the "add entry" dialog so it presents only the minimal required set of inputs on the first tab.

Solution

1. Remove all import functionality from the "add entry" dialog - imports can be handled from the import screen.
2. Improve the layout of the input fields to maximise vertical space for a mapping tool
3. Allow the user to provide distance in by:

• Drawing the route
• Choosing a favourite route
• Calculating based on average pace
• Specifying distance explicitly

1. Add route tab to non-GPS records.
2. Add a new "manage routes" view.
3. Add "extract route" action to GPS record

Wireframes

Draw New Route

Choose Favourite Route

Choose Favourite Distance-Only Route

Provide Pace

Explicit Distance

Notes

• Routes are not versioned - changes to a route will be reflected in all records that use the route. The user can be warned that they are potentially changing history when they modify a route and may be better off saving a copy.
• When creating an ad hoc route from the add entry screen the route name can be auto generated. It would probably use some combination of sport, date and location.
• To minimise the number of clicks, the UI should default to the same distance input method the user previously used to create a new record.

Other Ideas

• Have a favourites list per sport.
• Ability to search/sort routes by:
• name
• distance
• date first/last used
• location
• tags
• frequency
• sport
• When creating a route from a GPS entry there will be far more coordinates on the route than are necessary or useful. We can simplify the route using the Douglas-Peucker curve simplification algorithm. There's a Python implementation at http://mappinghacks.com/code/dp.py.txt. See http://screamyguy.net/SGImplify/index.htm (Java Applet) for an interactive demo.
• Allow GPS activities to be associated with routes
• Automatically match a GPS activity to an existing route. This requires a route similarity algorithm. See attachment similar2.py for a naive implementation. A more reliable algorithm should exist. Investigation into topics such as Similarity of Euclidean Graphs and Map Matching is required.

Remark(s) Comparing invariants as necessary conditions isn't naive because these constraints are quite restrictive. Geometrical analysis of (discrete) paths or trajectories (an euclidean graph is mathematically spoken something different!) is computational expensive. One might have to compare against dozens of preferred routes. Hash values can already be precalculated instead, so at least routes should be prefiltered by such a method. Empirics should show whether more detailed analysis will be needed.

Technical Design

Route Service

Database Schema

Map Integration

The route editor widget will be implemented using an embedded web renderer to load Google Maps or Open Street Maps. The route editor requires communication, in both directions, between the web renderer and the GTK UI. This is already done with the GPS map rendering feature and the waypoints editing feature but neither of them provide an elegant, reusable solution to this problem. I couldn't find any third-party solutions for this problem so have created https://github.com/ncjones/PyGtkWebWidget.

Implementation Steps

1. Create basic route editor widget.
2. Create Route service.
3. Modify Activity service to return route as part of activity (requires activity service refactoring).
4. Modify add/edit record dialog to include route
5. Display route on activity details view
6. Implement basic route management
7. Implement GPS route export
8. Add saved route selection to add/edit record dialog.
9. Implement favourite routes.
10. Delete redundant waypoints code.