How OpenTrails and OpenStreetMap can work together in the great outdoors.
With the Spring Mapathon ‘The Great Outdoors’ fast approaching, we want to highlight interesting developments and tools around open data for the outdoors. For this guest blog post, we invited Jereme Monteau of Trailhead Labs to talk about the OpenTrails standard, its relation to OSM and the TrailEditor tool.
We love parks and trails. We love maps. We love the web. If you’re reading this there’s a good change you do too.
To explore our many wonderful trails we have to know how to get to access them. It’s awesome to be able to walk to get to a trail, but sometimes we ride our bikes, sometimes we take public transportation and sometimes we drive. We need to know where the trails connect to roads or sidewalks or other transportation paths. These points are traditionally called trailheads. A nice trailhead will not only be the entry point to a trail, but it will also be a place where you can find more information, get drink of water, use the restroom, lock your bike or park your car.
These days, we look online for information about parks and trails first. Unfortunately, quality outdoor information, including the location of trailheads, can be hard to find. OpenTrails is a new open data format for sharing parks and recreation information. It is designed to make it easy for the outdoor community to publish comprehensive and consistent information about parks and trails in a way that can be easily consumed by applications. It was also designed with OpenStreetMap (OSM) in mind so that it would be easy to share data between OSM and OpenTrails. Many of the properties of the objects in OpenTrails map directly to commonly used tags in OSM. Let’s look at a trailhead to see exactly how this works.
OpenTrails uses CSV and GeoJSON files to describe the entire park system, including the park boundaries, trails and trailheads within the system and the organizations that manage and serve as stewards of these public resources. Trailheads are described in a trailheads.geojson file. This is what a single trailhead record looks like:
{
“type”: “Feature”,
“properties”: {
“id”: “th-2",
“name”: “Canyon Oaks”,
“steward_id”: “ebrpd”,
“segment_ids”: “segment-2",
“restrooms”: “No”,
“drinkwater”: “No”,
“parking”: “Yes”,
“kiosk”: “Yes”,
“osm_tags”: “natural=tree”
},
“geometry”: {
“type”: “Point”,
“coordinates”: [
-122.14586734771727,
37.775803045522146 ]
}
}
Type, properties and geometry are parts of the GeoJSON standard for geographic JSON documents. Let’s take a closer look at what is in properties.
ID
A unique identifier for the trailhead, not necessarily something for humans, but for machines to reliably tell trailheads apart.
name
A human readable name for the trailhead, you might use this as a label on a map or on a sign.
steward_id
Associates a trailhead with an administrative organization, which is defined in a stewards.csv file. This is typically a parks and recreation or other public agency.
segment_ids
Associates a trailhead with specific segments of trail Communicates the actual accessibility of a trail from a trailhead.
This is where it get’s interesting, because the following five fields were designed with OSM in mind. The names and values of these, as specified in the OpenTrails standard, map directly to commonly used tags in OSM.
restrooms
Is there a bathroom at this trailhead?
drinkwater
Is there a source of drinking water?
parking
Is there vehicle parking?
kiosk
Is there an information display?
osm_tags
This can be a list of any OSM tags that may be useful in describing the state of the trailhead. This is the primary extension mechanism of the OpenTrails standard. There exists a large subset of the OSM tags that may be applicable.
Because of the direct mapping of these fields and values, it is very easy to publish this information to OSM in the form of a Node.
Agencies across the nation are adopting OpenTrails right now for a number of reasons, including enabling better applications to built and collaborating with agencies across geographies and jurisdictions. Some agencies are able to create OpenTrails data from existing geo-databases they have maintained, but in many areas there is no existing Trailhead dataset.
This was the case in Portland Oregon when we visited to support the National Day of Civic Hacking in May of 2014. We had just finalized the first version of the OpenTrails specification. The event brought together an amazing group of community members, including developers, designers and employees of local government and non-profits that help manage the amazing outdoor resources in their region.
A small group expressed interest in exploring project ideas around the OpenTrails standard. After some brainstorming and discussing with some Zak from Oregon Metro, the agency that maintains an amazing open dataset of park information, our team decided to build a very simple system that let anybody create OpenTrails trailhead data by emailing geotagged photographs of Trailheads a web based service. After 24 hours of building TrailEditor was launched and the first few trailheads were created from emailed photos!
TrailEditor is an open source codebase and is currently hosted with support from my company Trailhead labs. There are currently over 300 trailheads spanning the world. We’re excited to see how it’s used in conjunction with other citizen science and citizen data projects, including the upcoming outdoor themed mapathons!
See you on the trail and on the map! You can learn more about OpenTrails at opentraildata.org
