Open Nayor opened 2 months ago
When searching for a route:
Related discussion on the backend: https://github.com/c2corg/v6_api/issues/1067
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)
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)
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)
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:
public_transportation_rating storage I think the route's public_transportation_rating storage is mandatory in order to filter routes quickly:
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
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
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 caseloop
, all access waypoints are starting points. No need to have an ending point in this casetraverse
,raid
,expedition
and at least 2 access waypoints are associated, the 2 farthest access waypoints are considered as starting and ending waypointspublic_transportation_rating
of the route is computed using the worst value bewteen :This algorithm may be applied to already existing routes, but it may require human checks to ensure data quality
When viewing a route
public_transportation_rating
of the route has to be displayed in the route headerWhen searching for an access waypoints
public_transportation_rating
filter must be a slider (instead of values selection: it's easier and quicker)When updating an access waypoint
public_transportation_rating
value of all the routes associated to the waypoint must be updated if this value has changedWhen searching for a route:
public_transportation_rating
filter (also a slider, as for waypoints)Alternatives considered
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 creationsoft_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 issuepublic_transportation_access
orsoft_mobility
checkbox route filter : easier and quicker than a slider, but allow less filter possiblity