RouteUnusedSegments facts caused by an excursion along the route

[pelderson]

The RouteUnusedSegments fact for this route seems to be caused by the side loop.
On the ground the route is continous for the hiker: the signs are put up nicely to guide the hiker through the loop automatically; no user choice involved. From an informational standpoint it is correct to add the common segment twice to the relation, so ideally it shouldn't raise a 'fact'.

Could this be done without additional tagging? If not:

• I thought about adding forward and backward roles to the common segment, but that would not be compatible with backward and forward roles in (mostly) cycling routes.

• Possible solution: we could give the side loop members the role "excursion". This role is designed and approved for this situation. However, the excursion should remain included in the route display, distance count, analysis of the segments etc. The role just needs to suppress the error.

[vmarc]

Last saturday I introduced an additional artificial node to cover a similar situation:
Route 79-79 was split in two:

*-79
79-*

This should be a temporay solution / workarround only.

The better solution will be that the knooppuntnet logic does not try to be too smart: when it finds that start and end node are nicely connected by the ways in the relation in the order in which they are in the relation, than it should think no further, stop further analysis and consider the route to be ok as is.

Additional tagging will not make it any easier for the mapper or the knooppuntnet logic I think.

See also: #2 (2017!)

[pelderson]

The better solution will be that the knooppuntnet logic does not try to be too smart: when it finds that start and end node are nicely connected by the ways in the relation in the order in which they are in the relation, than it should think no further, stop further analysis and consider the route to be ok as is.

Agreed! Can't wait! 👍