User:Pelderson/Validating Recreative Route Relations

(Work in progress; feel free to comment or contribute!)

Target: optimizing the structure and quality of Recreative Route Relations, i.e. route relations for walking, cycling, horse riding, inline skating, paddling, motorboat etc.

Method: define rules for validation, so validation tools can generate appropriate warmings and errors.

Extra: a few sidesteps to the idea of a special validation site, taking input from OSM, preprocessing the info, analysing the routes, then present them including the wanings and errors from the analysis, and links to maintenance tools (JOSM, mainly. You can do some things with Id, but when it gets complicated you need JOSM's relation editor).

Some related links: https://superroute.org/

https://bit.ly/2HrCM3j

Brainstorm: what do we have to deal with?

• hierarchy of route relations
  • Waymarkedtrails' pre-process looks good: replace child relations with their content, repeat until you only have way members (and maybe some nodes). type=route and type=superroute are regarded as the same, because any child relation can contain further children and any parent relation can be part of one or more higher parent relations. As a consequence of this process, child relations will also be there as routes in themselves. This should simplifiy maintenance, because you can fix the shorter child relations first, then step up to the longer parent.
  • If sorting problems can be attributed to the order of the child relations in a route relation, that's valuable information for maintainers.
  • Often, at the top of a hierarchy there is a "master route", in fact a collection of variants of a long-distance trail. This would almost by definition be a non-linear route, with many sidelines and discontinuous, so many validations will fail. How to handle this? Roles could be the answer, but so far they are not widely used.
  • Route reusing node networks routes ?
    The benefit is to minimize maintenance and reusing the knootpuntnet analyser.

• variants, roles
  • variants are indicated with member roles: main, alternative, approach, excursion, connection; no role equals main. The roles can be applied to way members and to relation members. If all the members with one particular role are selected, the validations should apply. (Or not? There could be multiple alternatives, so if you just filter by role "alternative" you end up with a discontinuous collection). So the waymarkedtrails hierarchy solving method is to be applied each variant separately.
• Combining traveling directions in one relation: backward/forward role. NB backward en forward roles on ways are not compatible with the functional roles. This is to be handled by the mappers, which should propably be a validation check.
  • These roles are used on ways, if a route in part uses different ways per direction of travel. In that case, each member way with a backward or forward role occurs only once within the relation, and the role indicates which travel direction uses this way. Increasingly, the forward/backward roles are used for ways which occur twice in the relation, because the route actually uses the way twice for one direction of travel. Can both these usages be checked and validated?
• Roundtrip
  • The roundtrip=yes key actually signifies the wish to count the route as a roundtrip, even if the relation is not a closed loop, or does contain a closed loop but has extras such as an approach or shortcuts.
• Future: multi-transport routes? a. The route tag has multiple transport values separated by semicolons; b. different sections of the route have different route= tags.

• Retrieval of routes from OSM.
  • Walking: object type=relation & type=route & route=walking|hiking|foot, NOT network_type=node_network
  • Cycling: object type=relation & type=route & route=bicycle|mtb, NOT network_type=node_network
  • Horse riding: object type=relation, type=route, route=horse, NOT network_type=node_network
  • etc paddling, motorboat, inline skates, ?skiing?

• Entry filters? Many relations will not even pass the basic requirements, so further validations cannot be applied.
  • Maybe first split:
  • a. Cannot be ananlysed in detail; global assessments
  • b. Can be analysed; detailed validation results.
• Presentation:
  • by continent/country/province or state/ municipality? Every route in or passing through.
  • Difference between routes which are just sections in a longer route (only show under the parent entry), and autonomous routes which together form a greater route (show as separate entry, but also under the parent entry)
  • Map view: a map with all the routes is probably unworkable. A map per route will be nice for the user (with some clickable methods)

Formal validations

• Sorted / sortable
• Continuity after sort: missing ways, superfluous ways; roundabouts (?); (pedestrian) areas; duplicate members (?) double members; member relations not continuous
• Unwanted members. Guideposts are ok.
• Access: members without access for the indicated transport.
• Mandatory keys with approved values: type=route|superroute; route=<transport> or <transport>;<transport>[;...]; network= (maybe not mandatory?); network:type tag is an exclusion
• Mixed way members and relation members (warning?)
• roundtrip=yes: must contain at least one roundtrip? Roundtrip=no: cannot contain a roundtrip?

Tag validations

? network: Transport is already in route=, and geographic scope is not strictly necessary. Maybe present as separate category: no geographic scope.

name tag: Check for not-really-name parts: ref, description, from/via/to, section_ref?

ref=* Validation criteria? E.g. all member relations of a route with one name should have the same ref?

symbol=*?

distance=* you could check if the distance is close enoug to the calculated length. May too much difference could be an exclusion criterion?

survey:date : might make a nice sorting column for a list?