Proposal: Routes

[ldodds]

Proposer

ODI, following discussions with TrainAsONE, Forestry Commission and Ordnance Survey.

Potential users would also include Canal and River Trust and British Cycling

Use Case

As a cyclist, runner or walker I want to find opportunities to run/walk/cycle

Why is this not covered by existing properties?

The data model currently covers events and facilities there is a partially defined "Activity Opportunity" for self-directed activities like walking, running and cycling but this doesn't say how to describe opportunities to run/walk/cycle, including information on the routes.

Please provide a link to example data

• Forestry Commission walking routes
• OS Get Outside Cycling Route
• OS Get Outside Walking Route

Proposal

The requirements we've seen so far cover providing metadata about the opportunity as well as some level of detail around the route. Data includes:

• name of route/opportunity
• author or creator of the route
• description
• link for more information
• date/time route was published
• activity type (e.g. walking, cycling)
• surface (although this is likely to vary across the route)
• distance
• difficulty or grade, e.g. moderate, easy
• elevation or terrain
• geometry of the route, either as GPX/line and/or start/finish lat/long, possibly with segmentation of the routes
• ratings
• tags, e.g. "pushchair-friendly", "family", "forest walk"
• amenities, e.g. is parking available
• dates/times when likely to be busy

To handle this, suggest we add a new type: Route which provides the metadata to describe the opportunity. We can build on existing vocabulary to describe the majority of features of a Route.

We will also need some new terms to refer to route, elevation, distance, startingPoint, etc

Things still to discuss:

• exactly how we link to downloadable routes, e.g. GPX, etc
• walking routes often have a duration as well as a distance

Example

From Forestry Commission data. Uses a custom startingPoint property to indicate start point as detailed route information might not be available?

{
  "@context": "https://www.openactive.io/ns/oa.jsonld",
  "type": "Route",
  "url": "https://www.forestry.gov.uk/forestry/englandeastanglianoforestthetfordforestparkgreathockhamgreenwalk", 
  "title": "Hockham Green Walk",
  "description": "The Green Walk is a pleasant walk through the forest at Hockham. Scots and corsican pine plantations blend with mature oaks stands, rich in insect and bird life.",
  "category": ["Forest Trail"],
  "activity": ["Walking"],
  "level": "Easy",
  "distance": {
     "type": "QuantitativeValue",
     "value": "2.1",
     "unitCode": "KMT"
  },
  "amenityFeature": [
    {
      "type": "Parking",
      "name": "Parking",
      "value": true
    }
  ],
  "startingPoint": {
    "type": "GeoCoordinates",
    "latitude": "",
    "longitude: ""
  }
}

Example from OS data. Uses url of a GeoShape to refer to GPX download

{
  "@context": "https://www.openactive.io/ns/oa.jsonld",
  "type": "Route",
  "url": "https://getoutside.ordnancesurvey.co.uk/adventures/bike-exploring-electric-mountain-bike-adventure/", 
  "title": "BIKE EXPLORING: ELECTRIC MOUNTAIN BIKE ADVENTURE",
  "description": "As part of #BigBikeRevival and #BikeWeek2018, Helen Pollard takes us on an electric mountain bike route from Castle Bolton to Askrigg.",
  "category": ["Cycling", "Helen Pollard", "Yorkshire Dales"],
  "activity": ["Cycling"],
  "level": "Easy",
  "distance": {
     "type": "QuantitativeValue",
     "value": "11.4",
     "unitCode": "KMT"
  },
  "startingPoint": {
    "type": "GeoCoordinates",
    "latitude": "54.322112",
    "longitude": "-1.9490007"
  },
  "route": {
     "type": "GeoShape",
     "url": "...GPX file...",
  }
}

Related

• distance #104 - also highlights need for distance
• Discussion: Should we remove Activity Opportunity? #64 - suggests changing Activity Opportunity, this proposal would replace it with a more explicit "Route" type.

[abs0]

Following up on the segmentation - on some routes easy access may be at a series of points (canal routes spring to mind)

[abs0]

Other possible aspects to consider might include

• Presumably ActivityType covers whether the route is suitable for walking, running, cycling, wheelchair etc. would it be useful to distinguish between "this is not suitable for cycle" and "this is from a walking route source which has not checked whether suitable for cycling"
• Is the route easy to follow, and well signposted where there may be path options

[TottenhamT]

Because it is so subjective, and depends on so many factors (such as who is doing the activity), duration could be left out if other factors were quantified perhaps. If you have a discrete data for distance, climb (perhaps an undulation factor such as @TrainAsONE use), and terrain (graded from 1-5?), then users of the data could add their own factors to generate durations that they were able to present without ambiguity.

[abs0]

Very much concur with @TottenhamT's comment - a key aspect of using this data should be to personalise for the individual - if I'm looking for a "two hour run" the route requirements will be wildly different from someone else.

What would definitely help would be a reference section which explains the grades & undulation factors and includes some sample routes with distances, undulation, terrain values and their typical expected duration for a reference runner (eg: for a four hour marathon runner this would be about X, for a three hour marathon runner it would be about Y).

Its a chunk of extra work for someone, but otherwise everyone could be flailing around either trying to determine what terrain & undulation values to put in, or conversely how to use the data when presenting to users

[blabyboy]

Agree with @abs0 point, there needs to be some consistency with what constitutes "easy" vs "medium", "hard" etc..

Suggest new property of 'isCircular' for same start/end point routes.

Additionally, I would suggest a property of 'Waypoints' that can be comprised of a GeoJSON object (https://tools.ietf.org/html/rfc7946) that would sit under a route, this would allow meaningful routes to still exist without necessarily having a full LineString to describe it if not available, but meaningful data can be provided for each waypoint e.g. is it an egress/ingress, condition under foot, direction to next waypoint, facilities at waypoint and so on.

For people with various disabilities/impairments you may need to consider things such 'pinch points' on a route e.g. where a wheelchair may not pass through, or a radar key may be needed. Condition under foot would be important for those with motor impairments potentially.

[nickevansuk]

Just to make this explicit here, we're using distance as a type QuantitativeValue which is different to schema.org. I agree with this wholeheartedly, just thought it was worth noting for clarity.

This being the case, I assume we're bundling in a definition of the property "distance" to Event too or creating a "route" property of Event @ldodds ? See #104 and beta issue https://github.com/openactive/ns-beta/issues/3 (which was blocked on resolving this)

          "distance": {
            "type": "QuantitativeValue",
            "value": "2.1",
            "unitCode": "KMT"
          }

[nickevansuk]

On the "easy" vs "medium", "hard" @blabyboy @abs0 check out #82 - any thoughts on @dolkensp's comment (#82 (comment))?

[abs0]

Another issue with routes is variation in terrain, undulation and suchlike over the entire route - there may be significant flat sections, then a hill, then flat again. Terrain could vary from a flat paved section to a very rough one (without any significant variation in undulation). Only some parts may be suitable for cycles or wheelchairs, etc.

I think the long term goal should be to break routes down into segments with specific characteristics, but initially it is probably better to just note that the issue is there, not yet addressed, and go for overall characteristics - though I like @nickevansuk comment in #82 regarding directly expressing as a list - in this case it would be so any route can naturally be indicated as both flat and not :)

[blabyboy]

@nickevansuk, I do think @dolkensp's comment is a good idea, and gives flexibility to the consuming agent, but it doesn't get away from the fundamental problem of qualifying what a 'level' would be i.e. one org's level 30 route could be equivalent to another org's level 50 - I hope you see the point. Perhaps suggesting the banding of levels as @dolkensp has done is the best way at present, until such time as standardised way to qualify a level is created (if ever).

[AUM3RLE]

Hello from the Ramblers, yes those ones. We are just in the process of consolidating our differing walk/route standards and would welcome the opportunity to be part of any consortium moving this forward

[nickevansuk]

Would also be great to have an example of a route inside an event

[nickevansuk]

Also suggest we have consistency of language, the "route" property should refer to a "Route" object as we've done elsewhere (e.g. "event"). Suggest the below should be a "geoShape" property, to make this really clear.

{
  "@context": "https://www.openactive.io/ns/oa.jsonld",
  "type": "Route",
  "route": {
     "type": "GeoShape",
     "url": "...GPX file...",
  }
}

[blabyboy]

Apologies, I missed the Routes call. I have referenced my responses against the Youtube recording at https://youtu.be/3m2_S8IFeZY

28:00. With regards to shared routes on the towpaths, I'd be minded to publish them separately, partly due to H&S considerations, but also because the actual lines may vary due to the path under foot/wheel and the routes become specifically shareable with other routes of the same 'type'

32:45. Suggest StoppingPoints becomes WayPoints as that feels more in-keeping with the lexicon of Routing and Navigation. You may not always stop at a WayPoint but it can provide useful pointers that you are on the correct route overall.

34:20 We have an internal format but we publish as GeoJSON - an established standard and easily readable.

~40:00 For 'advanced' routes it would be good to have a Segments or Sections property and allow GeoShape objects to be assigned to those. You can then have a GeoShape property for the whole Route, but also pick out specific sections within a route for highlighting against the overall route on a map for instance, or to mix and match with other Routes or Sections available.

This would allow a consumer to create a bespoke Route of a specific activity from various datasets e.g. a walking route that transgresses a park segment onto a canal towpath segment and then onto a NT segment. We record various types of asset along a towpath such as toilets (whether they are key-based or public) which could be published as amenities if publicly accessible.

[jnicho02]

I like to look at existing cases and see whether they would fit the model:

I adopted a greyhound and want to know where I could/should walk her, whether there is a car park, and if I can safely let her off the lead. I get personal recommendations from a Facebook Group and ask locals. Sites like https://walkiees.co.uk/walks/sussex-east help, and i am able to submit walks as well. It has the lowest common denominator of a geolocation for the start of the walk and a textual description. I would have liked to have seen a rough route of waypoints. The single geolocation of the walk could have been a centroid but people probably want to know where the start point is.

I also use walking books, which are an age-old model for sharing a route. They have a simplified map plus a more detailed textual description of waypoints. So, i'm now thinking, "could I generate both 'views' from the same data?"

HTH

[blabyboy]

They have a simplified map plus a more detailed textual description of waypoints. So, i'm now thinking, "could I generate both 'views' from the same data?"

@jnicho02
Have you got a link to an example simplified map? For me, I do not think you could generate both 'views' as the depth of data is not there in the spec at present i.e. waypoints/segments/sections. If there were waypoints/segments/sections you could choose to leave some out based on an algorithm of your own definition and the same could be applied to Linestring geodata (if it was included) - the trick being to know which parts of the line should be simplified ;)

You are the one reading the data in from a feed and then transposing it as you best see fit for your requirements. So, as long as the data exists in the feed then you can pick and choose what you take and how you display to a User. My gut feeling is that the Route data would/should be enough to provide you with a dataset to generate your simplified map view and if there were segments/waypoints/sections then these could provide a more detailed view. You could even take properties of these segments to add nuance to the simplified view if needed.

It might be worth you jumping on the next call for Routes on 23rd May so you can contribute.