[Patch] Unneeded "turn:lanes:forward without lanes:forward" warnings

[aceman]

JOSM 16812 started to issue a validator warning like "turn:lanes:forward without lanes:forward" also on roads that have an even number of lanes. In such case, it is implicit that on a oneway=no road there are half number of lanes in each direction. So what is this warning for? It didn't happen in the past.

[skyper]

See #10932 (r16769).

What is your suggestion? Downgrading the test to informal for even numbers of lanes and number of values *:lanes:[backward|forward]=* are half of value of lanes and no *:both_ways=* present ? The problem is that as soon as there is a lane which does not count to lanes like bicycle:lanes* or short bus:lanes* on a stop (passing_lane) the situation is quite complicated without lanes:[forward/backward]

[aceman]

I don't know, I just say this warning is new and reports false positives. It is also true that the number of lanes described in *:lanes tags is allowed to be more than those in the 'lanes' tags (as those only count car-wide lanes). And JOSM does not warn of those (which is correct). How does explicitly tagging lanes:* help in the situation? Do you at least try to check that it is lower or equal to those in *:lanes ?

[skyper]

I had a look at it and I tend to simply downgrade the test for lanes:forward/backward to informal and exclude more cases matching other tests.

The test for lanes:* vs. *:lanes is only run for motorway[_link]/trunk[_link] on hard implemented keys and both_ways` is ignored.
There is a informal warning about only one of lanes:forward/backward and a test for uneven lanes=* without lanes:forward/backward.

The interesting cases are even number of lanes where the number of lanes per direction are not equal and cases with higher number of values of *:lanes than lanes:*.

I did not understand, yet, how to completely work with lists in mapcss. How do I get the values from tags matching a regex like /^.*:lanes:forward$/ to split them at | and count the values to check that they have the same number of values and that the number is equal or higher to lanes:forward.

[skyper]

first patch still needs some testing and some cases are missing.

[skyper]

Replying to aceman:

I don't know, I just say this warning is new and reports false positives. It is also true that the number of lanes described in *:lanes tags is allowed to be more than those in the 'lanes' tags (as those only count car-wide lanes). And JOSM does not warn of those (which is correct). How does explicitly tagging lanes:* help in the situation? Do you at least try to check that it is lower or equal to those in *:lanes ?

There is Lanes.java​.

Some test are not possible in MapCSS right now, as working with lists and matrixs is not well supported, yet.

I`ve attached a first version of a possible fix (josm_19609_wip.patch​) which:

• add a warning for missing lanes=* with *:lanes:forward/backward=*
• excludes highway=motorway from "odd number of lanes" test as oneway=yes is implied and there is another informal warning about missing oneway=*
• downgrades the general warning for missing lanes:forward/backward to informal and fine tuning
  • exclude several cases which have an own warning, like odd numbers of lanes or existing lanes:forward/backward=*.

[skyper]

Found no problem. Think the patch can be applied.

There are still cases in the example file where a warning is needed but this is a different story for an own ticket.

[skyper]

Replying to skyper:

There are still cases in the example file where a warning is needed but this is a different story for an own ticket.

See #19653.

[skyper]

update of example file

[Klumbumbus]

In 16860/josm:

fix #19609 - Adjust lanes warnings (patch by skyper)

[Klumbumbus]

Thanks skyper. Please don't add further `{0}` in translations strings (this will require a retranslation after #11153) and try to reuse translation strings if possible.

[skyper]

Replying to Klumbumbus:

Thanks skyper. Please don't add further `{0}` in translations strings (this will require a retranslation after #11153) and try to reuse translation strings if possible.

Sorry, was not aware of this ticket.