Feature: add transport information (and associated filters) to routes

[Nayor]

Community discussion about this feature (mandatory)
Link to https://forum.camptocamp.org/t/projet-mw-ticket-131-amelioration-des-infos-transports-en-commun-tc/73092/47 where this feature has been validated

Expected behaviour
When creating the route

• It must be possible to select starting points and ending points (which have to be access waypoints) in the route configuration section, just after selecting the route type. They are automaticaly estimated by the following algorithm:
  • If the route is of type return_same_way, loop_hut and only one access waypoint is associated, this point is the starting point. No need to have an ending point in this case
  • If the route is of type loop, all access waypoints are starting points. No need to have an ending point in this case
  • If the route is of type traverse, raid, expedition and at least 2 access waypoints are associated, the 2 farthest access waypoints are considered as starting and ending waypoints
• Based on these points, a public_transportation_rating of the route is computed using the worst value bewteen :
  • the best accessibility value of all starting points, and
  • the best accessibility value of all the ending point (if they exists)

This algorithm may be applied to already existing routes, but it may require human checks to ensure data quality

When viewing a route

• A public transport logo 🚍 has to be dislayed on associated waypoints accessible by public transports
• A play ▶ logo has to be dislayed on starting waypoints
• A stop ⏹ logo has to be displayed on ending waypoints
• The public_transportation_rating of the route has to be displayed in the route header

When searching for an access waypoints

• The public_transportation_rating filter must be a slider (instead of values selection: it's easier and quicker)

When updating an access waypoint

• The public_transportation_rating value of all the routes associated to the waypoint must be updated if this value has changed

When searching for a route:

• It must be possible to filter routes with a public_transportation_rating filter (also a slider, as for waypoints)

Alternatives considered

• A public_transportation_access information (a checkbox for instance) provided manually when creating the route, in order to certify that this route is accessible by public transportation. IMHO, this information has to be provided by the access waypoint information ; in this way the information is only provided at one time/place, and all the route linked to this waypoint are updated when the waypoint is. Inconvenient: it requires existing and updated access waypoints, or it needs waypoints creation apart from route creation
• A soft_mobility_outings information on the route header (yes/no if at least one outing has been associated to this route or outings associated to this route number). I don't know if it's relevant in this issue
• A public_transportation_access or soft_mobility checkbox route filter : easier and quicker than a slider, but allow less filter possiblity

[eddy-geek]

When searching for a route:

Related discussion on the backend: c2corg/v6_api#1067

[eddy-geek]

IMHO, this information has to be provided manually when creating the route, in order to certify that this route is accessible by public transportation.

Completely agree. Generally speaking the c2c data model is well thought-out and very flexible, BUT we need to surface it better in the UI:

It would be nice if any information about those access point was shown inline in the route page instead of requiring an extra click (which will very often lead to a poorly-filled access point details because these page are not much used currently).

(If people agree, this should probably be a separate issue)

[Nayor]

It would be nice if any information about those access point was shown inline in the route page instead of requiring an extra click

I Agree
I'm thinking about a starting waypoint and ending waypoint document selector close to the waypoint selection, in order to them to specific lists (they will still be added to waypoints to avoid any breaking changes to the api or the data structure)

[eddy-geek]

I like the proposal overall, 2 comments:

Naming: start/end vs access: for most activities (all except paragliding and ski with lifts?) "end point" does not have a strong meaning separate from starting point. Many crossings (traverse, raid, expedition) don't have the 2 "directions" as distinct routes. And anyway for automatic estimation of existing routes it would be random which one is start/end I guess?
so maybe the data model for storage of the results of "the algorithm" / manual tagging should be simply a list of 1 or 2 "access points" without naming them start/end ?

Caching: for public_transportation_rating of the route, I'm wondering whether storing it is mandatory? maybe a bit simpler algorithm (best accessibility value of all access points) could be implemented directly in search, if it doesn't slow it down too much? We also return them in the API like Florent suggested, and this way we avoid having to maintain things in sync when access points are edited?
(I'm frankly not sure which solution is best)

[Nayor]

Naming: the end access is mainly for crossings (which of course can be done back and forth most of the time)
It is needed because if there is no service at the end, the crossing cannot be done using public transportation, even if there is good service at the start
An other idea:

• Replace the main waypoint select list by a waypoint search (it will be added to waypoints)
• Move waypoints selection (start, end, intermediate) to the configuration section, after the route type selection. Ending waypoint section will be shown only if crossing route types are selected. The risk is that less waypoints may be inputed because this field will be in the configuration section.

public_transportation_rating storage I think the route's public_transportation_rating storage is mandatory in order to filter routes quickly:

• The api is currently designed to filter on the searched element attributes only
• There are about 42k routes and 6k access waypoints, crossing them means a heavy request
• This way of filtering only allows very limited operations
• The sync is already done with the route title (which is linked to the waypoints title), it's not very complicated to do on the backend

[Nayor]

I've send a first pull request for the backend, without the starting and ending point part
The starting and ending estimation allows to compute a public_transportation_information for 75% of all routes (2018 data)
May be we can test this way to check if it fill the need ? And add the starting / ending point selection afterwards if it's relevant