[Monitor] Inconsistent number of segments

[StC-OSM]

On some routes, the number of segments displayed in the Details tab is much lower than the number displayed in the Map tab. See below:

[vmarc]

GR 365

The 114 segments in the map page reflect the situation as found in the route relation. The large amount of segments is mostly due to the wrong sorting order of the ways in the relation.

The 7 segments in the detail page are the result of merging adjacent segments into bigger segments (called super segments in the code). This merging logic is normally only intended to be performed on all segments in nested routes (route relations with other route relations as members). The idea is that for example when a superroute consists of 5 subroutes that are together continuous, the superroute would show only 1 segment instead of 5.

The inconsistency in number of segments can be avoided by not performing the merging logic on individual route relations, but only on the parents in nested route relations.

Note: when sorting the route members in JOSM, this results in 5 segments. The the logic for merging the segments results in 7 segments and not JOSM's 5. This is because the logic assumes that the route starts at the first member in the relation (which is currently not the case).

[pyrog]

The inconsistency in number of segments can be avoided by not performing the merging logic on individual route relations, but only on the parents in nested route relations.

👍

But what happened when (the parent) route have mixed members (relations and ways) ?
Also the result is probably still false for complex routes i.e. with the follow shape --<==>-- ?

[StC-OSM]

As for "super-segments", @pyrog and I have been giving some thoughts to the difficulties in deciding whether a discontinuity is legitimate or not. Roles assigned to sub-relations help sometimes, but not always:

• sometimes operators do not defined a route as main and another route as alternative; they can be East and West, or North and South.
• alternative routes can be connected at their two ends, as pictured in @pyrog's message above; or they can be connected at one end only.
• etc.
  Ultimately, there is probably not enough information for the algorithm to decide to report a warning or not.

We have come up with a candidate solution: we add nodes to the super-relation (possibly with a dedicated role) everywhere there is a connection or starting point expected. From this, you can use the same kind of logic as in node networks to determine whether things are OK or not.

Your thoughts?

[vmarc]

From this, you can use the same kind of logic as in node networks to determine whether things are OK or not.

I am currently rewriting the logic for the route analysis. Especially the node network route analysis will change to be much closer to how the monitor logic currently works and how JOSM looks at the route relations. There will be no more sorting of the relation members, the members will be interpreted in the order as found in the relation.

During this rewrite the logic for route relations with nested route relations should also improve (proper handling of relations that mix ways and relations, member roles, etc), but I am currently not at that point in the code yet. When I get that far, it would be good to work from concrete example routes to find out where not enough information is available.

[StC-OSM]

I can suggest Voie de Tours, E2 and E5 as examples. There also are more complex situations mid-way between routes and networks in V22 (cycling route) and Sentier de Provence (Mines et Energie).