Wrong *:lanes counting

[mdk]

I have tagged a highway with oneway=yes, lanes=2 and destination:lanes=A14|A2. The validator complains about Number of lanes greater than *:lanes. When I change the value to destination:lanes=A|B, the warning disappears. But also destination:lanes=A|B|C didn't cause a warning, even if there are 3 values for only 2 lanes.

For me this looks like the validator is extracting a number from the value instead of counting the separated values.

I search taginfo for common usage of *:lanes tags and I found 3 different value types.

1. According to the wiki ​http://wiki.openstreetmap.org/wiki/Lanes there are separate values for each lane separated by the '|' symbol. In this case the number of these delimiters must be count. The number of lanes is number of delimiters +1. This should be implemented (see #8519) but it doesn’t work correctly in this case. The most used keys are: turn:lanes, change:lanes, destination:lanes, access:lanes, width:lanes, bicycle:lanes, bus:lanes, psv;lanes.
2. Some keys like note:lanes and source:lanes only have a single text value and could be ignored for lane counting.
3. The last group has keys like proposed:lanes or piste:lanes which have a single integer value.

We can distinguish between the different value types the following way (pseudo code):

if (value.contains('|')) {
   lanes = value.count('|') + 1;
} else if (value.isInteger()) {
   lanes = value;
} else {
   ignore this tag;
}

Only use the value as integer, if there are absolutely no other characters than '0'-'9'!

In the attached file destination:lanes=A14|A2 shouldn't cause a warning, but bus:lanes=no|designated|yes should cause a warning instead.

Perhaps this validator test messed up *:lanes and lanes:* values. The more unspecific keys like lanes:psv or lanes:bus really have integer values in contrast to psv:lanes or bus:lanes.

The "Lane and road attributes" map paint style is very helpful when working with these keys.

[simon04]

• Concerning the "warning expected" in the test file, please check the lengthy discussion in #8519 (especially ticket:8519#comment:3).
• Concerning the "no warning expected" in the test file, please note that destination:lanes = A14]A2 instead of A14|A2 (closing bracket instead of pipe).

Case 2, note:lanes=foobar, is hard to distinguish from bus:lanes:backward=yes). So maybe we should exclude some specific keys from testing …

[imagic]

Simon04 already answered most of the points.

But here mdk is correct:

2. Some keys like note:lanes and source:lanes only have a single text value and could be ignored for lane counting.
3. The last group has keys like proposed:lanes or piste:lanes which have a single integer value.

These should not be checked.

The "Lane and road attributes" map paint style is very helpful when working with these keys.

Thank you - tried my best.

[Don-vip]

source:lanes is not checked anymore since r7497 (see #10480). We can extend this blacklist to other keys as well.

[Don-vip]

In 7888/josm:

fix #10083 - exclude more keys from *:lanes test

[rickmastfan67]

I think there should be a way for note:lanes to be checked. There was a user here in the US that put the info for the lanes:forward and lanes:backward in that key instead, and he did this all across the US.

There should be a way to flag this to alert the user to fix it.

​https://taginfo.openstreetmap.org/keys/note%3Alanes#values

[Don-vip]

this is a one-time job. I don't see this strange error as something going to happen again, am I right? In that case I think a MapRoulette project with some overpass queries will be more valuable to the US community than a new JOSM test.

[rickmastfan67]

I guess you're right about it being a 'one-time job'. Just thought I'd mention it anyways.

[aceman]

Replying to Don-vip:

In 7888/josm:

fix #10083 - exclude more keys from *:lanes test

I fail to understand how this patch fixed the problem of wrong warnings on tags like "destination:lanes=A14|A2" from the bug report. Can anybody please enlighten me?

[Don-vip]

There was no problem. The data is wrong, the value is A14]A2 as Simon already said.