TrailScraps

Yo, Robot!

Overview

The basic idea is for a "trail scrap book", which would recreational users of parks (hikers, mountain bikers, equestrians) to compose sections of GPS trail data into routes and obtain information concerning them. It expressly is NOT to be just a bag of "trip reports" with GPS track data on complete hikes or rides. Ancillary information, such as photos, writeups and dsiscussions might be available, but the core of the service would be the ability to composite routes visually from sections of GPS data. In keeping with this practical purpose, "planning" information, such as entrance data, hours, parking capacity, fees, type of trail and so on, WILL be included.

The "feel" of this operation is somewhat different than normal point-to-point street mapping programs, which are geared to finding the most efficient route. We are aiming for an interface which lets you start at an entrance, and "armchair hike" the park, composing something you want to go try, which probably isn't an "efficient" route in any sense of the word.

The output of the users planning process would be:

1. A printable "hike plan" document, to include maps, notes, elevation profile, etc.

2. A GPS file to download to your GPS unit. It contains the composed track information, as well as waypoints from the standardized set, which mark trail junctions, entry points and points of interest on the hike.

The standardized waypoint information is intended to be useful given the small screen / limited labelling ability on a handheld device, and could be provided separately from a composed track on a per-park basis. To this end, the "navigation" waypoints to be provided by the service:

• Use a very small icon, where permitted by the file format.

• Have abbreviated symbolic names based on short abbreviations for trail names and a standard convention for concatenation. If you are IN a particular park, and know about where you are, you can realize that "SUM" means "Summit Trail" or whatever, and the waypoint label doesn't take too much of your screen real estate.

The waypoint conventions are described in more detail here.

A mockup of the sort of thing the user would be presented with (links and buttons are non-functioning). See notes following the mockup:

Notes:

This is actual trail and map data from El Corte Madera Open Space Preserve. The user has started composing a hike, started in from Skeggs Point, and chosen the El Corte Madera trail, followed by the Tafoni trail, followed by the Fir Trail. They have clicked on a further section of the Fir Trail, continuing from the junction with the Resolution Trail to Methusalah Trail, and may add that to their hike.

(For my current experimentation, I'm using El Corte Madera as a good test of concept because of its maze-like welter of trails. The GPS track data I used for this mockup is missing the section of the Methusalah trail from the Fir trail to the Manzanita trail. On the hikes I collected the data from, I seem to prefer using the Giant Salamander / Timberview trails. I should make the side trail to the Tafoni Sandstones a seperate segment. And yes, I know that the El Corte Madera may not technically start at CM01 (offhand, I can't remember how the trail markers are labeled). If so, it's such a short section on Fir that you might choose to model it that way, and just note that the trail actually turns off a short distance from the entrance, rather than expecting someone to choose a tiny little trail segment.)

The currently composed hike shows the distance, elevation difference beginning to end, and the accumulated gain for each segment, and the current total.

While we use "park" as an important division in our classification scheme, the intent is that there be no impediment to a user composing a hike across park boundaries. Continuing or connecting trails (easements), or short road walks between parks should be included in the data, and appear on the user's map. It probably WILL be the case that a chosen trail segment will not span parks. The user will choose a trail segment which hits the park boundary, and then have to choose a connecting one outside the park to continue on. This is actually a feature, reminding the user that the hike they are constructing crosses park boundaries, or utilizes an easement across private property. For example, the user starting in El Corte Madera could "hike" to CM04, and find that they can connect to the trails across the road in Wunderlich, or the Bay Ridge Trail to continue on into Huddart / Purisima.

The mockup gives a rough idea of the intended interface. A lot of refinement would take place. For instance, the listing of the currently composed hike should probably be a sidebar which could be opened and closed, which would allow acceptable use for limited screen real estate.

Other features available to the user:

• Map controls for finding places and specifying the type of map. In this mockup, we're supposing that you can slide the map image around, ala Google Maps. One assumes that we would get a great deal of the map navigation abilities from the vendor widget we use to display maps.

• Truncate the current hike to a particular segment, or clear it and start over.

• Operations with the hike plan:

• View it in its current state.
• Print it out.
• Save it locally.
• Restore the hike from a saved hike plan.
• Provide a link to the current hike for other users of the service.
• Download the GPS data in the more popular formats.

The user would probably also register to use the site, which means we could store their current session for recovery when they come back, and they would have a profile helping to control their options. For instance:

• The user might be interested in hiking / biking / horseback riding, or have special requirements (dog walking, small children, etc) which should restrict the trails shown to them. Presumably, if they were equestrians or bikers, that would also make "hike" text in the GUI read "ride".

• The user's location has to be taken into account. They only want to consider starting locations a certain road distance from their home / group meeting point, etc.

• Control visbility of linked hike plans.

© copyright, 2005-2022, Robert L. McQueer

Powered By