Relations are not sorted/visualized when only one oneway branch is connected

[PetrDlouhy]

Relations are not sorted/visualized when only one oneway branch is connected.

More about this is written in on ticket #5109.

Here are some images, how some more complicated examples from relation_analysis.osm​ should be visualized and sorted:

Example 3:

Example 4:

In example 8 from that file, it should be clear on first sight, that something is wrong.

The example 7 could be also considered as this bug.

[PetrDlouhy]

There is implementation problem with this - it is needed to analyze the relation from both directions (or with returning). Current implementation can determine properties of the route element in one pass (except plain loops, when return is required).

The bidirectional analysis can be implemented, but will cost some code rewriting, some things might be simplified, though. I would appreciate more diverse cases, that would matter to bidirectional analysis.

There is also second level - the sorting.

[bastiK]

Here is some concept. A real implementation is much more work, of course, but maybe this can be some kind of inspiration!

Say, all members between member a and member b have the role forward/backward so they form a 2 lane section of some kind.

• try to create 2 "strings" from a to b
  • if it succeeds, but there are still members left, these superfluous member should be marked somehow and the 2 strings can still be rendered continuously

    topology:
    
         | a
     l1 / \ r1      s1 |
    l2 |   | r2
    l3 |   | r3     s2 |
    l4 |   | r4     
     l5 \ / r5
         | b
    
    member order: a l1 l2 s1 l3 l4 l5 r1 s2 r2 r3 r4 r5 b
    
    rendering:
    
         | a
     l1 / :   
    l2 |   :
    s1 : | :
    l3 |   :
    l4 |   :
    l5 |   :
       :   | r1
    s2 : | :
       :   | r2
       :   | r3
       :   | r4
        : / r5
         | b
    

  • it fails, but there is one string

    topology:
         | a
          \ r1
    l2 |   | r2
    l3 |   | r3
           | r4
     l5 \ / r5
         | b
    
    member order: see rendering
    
    rendering:
         | a
          \ r1
    l2 |   :   
       :   | r2
       :   | r3
    l3 |   :   
           | r4
    l5 |   :  
        : / r5
         | b
    

    • render this string normally
    • the connection properties of the remaining members are analyzed as if the other string would not be present: a l2 l3 l5 b. In this case l2 is connected to l3, and l5 is connected to b. These connections are shown on the other lane.
  • it fails completely, no string can be constructed. In this case there should be 4 loose ends: 2 strings connected to a and 2 strings connected to b.
    • lets say all members are in one of these 4 strings. Then the remaining question is which string to put left and which to put right. It should be possible to apply some direction heuristic to make a sensible decision.

      topology:
      
           | a
       l1 / \ r1     
      l2 |   
      l3 |   | r3    
             | r4     
       l5 \ / r5
           | b
      
      rendering:
      
           | a
       l1 / :   
      l2 |   :
      l3 |   :
             :
      l5 |   :
         :   | r1
         :    
         :   | r2
         :   | r3
         :   | r4
          : / r5
           | b
      

    • there are still more members left

      topology:
      
           | a
       l1 / \ r1       s1 |
      l2 |   
      l3 |   | r3      s3 |
             | r4      s4 |
       l5 \ / r5
           | b
      
      rendering:
      
           | a
       l1 / :   
      l2 |   :
      s1 : | :
      l3 |   :
             :
      l5 |   :
         :   | r1
         :    
         :   | r2
         :   | r3
      s3 : | :
      s4 : | :
         :   | r4
          : / r5
           | b
      

[bastiK]

Replying to Petr_Dlouhy:

There is also second level - the sorting.

I wouldn't care for sorting too much. This can be done later (as long as it sorts properly in the non-broken case).

[skyper]

Anything left that is not covered by #6166, #6920 and there was another ticket with nice examples I do not find right now.