Author: Polyglot
[Added to the original trac issue at 10.38am, Thursday, 23rd August 2012]

Those rcn and rwn relations are being meticulously entered. So I would be very surprised if it where a data error. I also ran my QC script on the rcn route relations 2 days ago. They are all correct.

I think Jw found the cause of the many routes shown as xx- or -yy. The data of the other side of the relation isn't loaded yet.

What should really be done to determine what should be displayed is to load the relation. Take the first and the last way of the route relation and find the rwn_ref or rcn_ref of their nodes, of course rwn for rwn routes and rcn for rcn routes. There are also rhn routes with numbered nodes, BTW. Not many yet, but they do exist.

If the previous algorithm produces 2 numbers, you are done. If not, more ways should be investigated, as there is some funny stuff going on in rcn relations. (Having to do with routes that end on 'cycle network nodes' that need to be represented by more than 1 OSM node, on different sides of a street/canal/roundabout/etc). This will only occur if those ways have forward or backward roles.

I hope this helps to resolve the issues.

Kind regards,

Jo

Author: JDub
[Added to the original trac issue at 10.47am, Thursday, 23rd August 2012]

Replying to [comment:1 Polyglot]:

I think Jw found the cause of the many routes shown as xx- or -yy. The data of the other side of the relation isn't loaded yet.

Well, this may not always be doable, as if it's a long relation it may require too much memory. However, even if we accept that only one endpoint is shown as is now, relation 6115 is still being detected incorrectly despite that the endpoint is in the active data set.

Author: Richard
[Added to the original trac issue at 10.53am, Thursday, 23rd August 2012]

Jo is right, the issue is that the other end of the data isn't loaded yet. We absolutely can't load /relation/full for everything just to get naming right on this one edge case - that would kill the servers for the 99.9999% of other uses. We could potentially add a 'Load relation contents' option to the relation contextual menu, I guess.

I can't reproduce your error for 6115; that works fine for me as soon as the data is loaded into memory and you re-click on the way to update the display.

Author: Richard
[Added to the original trac issue at 11.04am, Thursday, 23rd August 2012]

(If you want to look at the existing code and maybe submit a patch if it's not doing what you want, it's at https://github.com/systemed/potlatch2/blob/master/net/systemeD/halcyon/connection/Relation.as#L132 .)

Author: JDub
[Added to the original trac issue at 1.15pm, Thursday, 23rd August 2012]

How I reproduce the error:

• Open my link above, then Edit -> Potlatch2

• Without zooming, select way 73579617, the small connection between the road and the bike path.

• Select advanced view. One relation is listed as using this way, namely "Route bycicle rcn -60", id 6115. The end points of this relation are 872014261 [rcn_ref=75] and (off-screen) 60457713 [network=rcn, rcn_ref=73, rwn_ref=69]

• If I stay in simple view but try to add this way to a cycle route, I get three options in the resulting window: "13186: route bicycle rcn 75-", "6115: route bicycle rcn -60" and "6119: route bicycle rcn -75". All three of these meet in rcn node 75.

If I zoom out enough that rcn node 73 is in the picture, and wait for my computer to stop swapping (it's a laptop), relation 6115 is reported as "route bicycle rcn 73-60". This is despite that it correctly recognizes that short segment ending on rcn node 75 as the last one of the relation (6115/28 for 29 members)

It shows you that relation as "route bicycle rcn -75"?

Took a look at the code, and here's my understanding of what's going wrong:

Relation 6115 is loaded, as is its last member way 6115/28 and this way's two end nodes 872014261 and 16652149. Calling getDescription(6115) then calls getSignificantName(6115/28), which in turn first tries getSignificantName(16652149) and then, if this gives no result, getSignificantName(872014261) which should be "75".

However, node 16652149 is rwn node 60, so getSignificantName(16652149) returns "60". The problem is that getDescription takes the a node of last way but not necessarily the last node of the relation. Reversing the direction of the way would fix it for the -75 routes, but this might not fix other, busier intersections.

getSignificantName() either needs a flag indicating which end to check, or the relation needs to be able to directly find the first and last nodes and call getSignificantName (or maybe just the needed regex) on them directly.

I'm not familiar with ActionScript, but what about something like this, replacing lines 149-151:

var firstName:String = '';
if (getFirstMember() is Way) {
    if (Way(getMember(0)).getFirstNode()==Way(getMember(1)).getFirstNode() || Way(getMember(0)).getFirstNode()==Way(getMember(1)).getLastNode()) {
        firstName = getSignificantName(Way(getMember(0)).getLastNode());
    } else {
        firstName = getSignificantName(Way(getMember(0)).getfirstNode());
    }
} else if (getFirstMember() is Node) {
    firstName = getSignificantName(getFirstMember());
}

var lastName:String = '';
if (getLastMember() is Way) {
    var len:Number = length() - 1;
    if (Way(getMember(len)).getFirstNode()==Way(getMemler(len-1)).getFirstNode() || Way(getMember(len)).getFirstNode()==Way(getMember(len-1)).getLastNode()) {
        lastName = getSignificantName(Way(getMember(len)).getLastNode());
    } else {
        lastName = getSignificantName(Way(getMember(len)).getfirstNode());
    }
} else if (getLastMember() is Node) {
    lastName = getSignificantName(getLastMember());
}

if ((firstName+lastName)!='') desc+=" "+firstName+"-"+lastName;

There's probably a more elegant way to code this, but this way should work at least.

Author: JDub
[Added to the original trac issue at 9.31am, Tuesday, 28th August 2012]

Hacked at it a bit and got it working properly on my machine. Is this the proper place to submit patches?

Author: JDub
[Added to the original trac issue at 11.35am, Tuesday, 28th August 2012]

Replying to [comment:6 JDub]:

Is this the proper place to submit patches?

I've created a pull request on GitHub, so there's no need to use the attached patch.