Lane count validation

[gaben]

The current lane validation rule only warns if the lanes < lanes:forward+lanes:backward values.
I think a not equal rule would be more useful.

What steps will reproduce the problem?

1. Tag a way with eg. lanes=3 lanes:forward=1 lanes:backward=1
2. Run the validator

What is the expected result?

A warning informs the user that the values don't match

What happens instead?

Nothing

Please provide any additional information below. Attach a screenshot if possible.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2019-12-29 22:32:02 +0100 (Sun, 29 Dec 2019)
Revision:15624
Build-Date:2019-12-30 02:30:57
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (15624 hu) Linux Debian GNU/Linux 10 (buster)
Memory Usage: 321 MB / 1990 MB (81 MB allocated, but free)
Java version: 11.0.5+10-post-Debian-1deb10u1, Debian, OpenJDK 64-Bit Server VM
Screen: :0.0 1912x1020
Maximum Screen Size: 1912x1020
Java package: openjdk-11-jre:amd64-11.0.5+10-1~deb10u1
Java ATK Wrapper package: libatk-wrapper-java:all-0.33.3-22
fonts-noto: fonts-noto:all-20181227-1
Dataset consistency test: No problems found

Plugins:
+ tageditor (35258)
+ turnlanes-tagging (283)

Last errors/warnings:
- W: No configuration settings found.  Using hardcoded default values for all pools.

[Don-vip]

related to #16395

[gaben]

After reading some comments in #8519, I got a bit confused. Maybe implementing the validation on more important highways, like residential, tertiary and up is enough?

I see a possible problem with shared cycle- and footways, but these aren't going to get the lanes:forward and lanes:backward key in my opinion.

[skyper]

Replying to gaben:

After reading some comments in #8519, I got a bit confused. Maybe implementing the validation on more important highways, like residential, tertiary and up is enough?

I think you do mix up "access" and "lanes".

I see a possible problem with shared cycle- and footways, but these aren't going to get the lanes:forward and lanes:backward key in my opinion.

Both lanes:forward and lanes:backward where not demanded from the beginning but common practice developed to add both. So, when there are at least two lanes:* the sum should be equal to lanes. Do not forget lanes:both_ways.

[gaben]

Replying to skyper:

I think you do mix up "access" and "lanes".

Why do you think that? 😀

I see a possible problem with shared cycle- and footways, but these aren't going to get the lanes:forward and lanes:backward key in my opinion.

Both lanes:forward and lanes:backward where not demanded from the beginning but common practice developed to add both. So, when there are at least two lanes:* the sum should be equal to lanes. Do not forget lanes:both_ways.

Just looked up the wiki (​https://wiki.openstreetmap.org/wiki/Key:lanes) and there is an example, where it says the
lanes=3
lanes:forward=1
lanes:backward=1
is a valid combination. I think it shouldn't be used this way, but with lanes:both_ways because this makes the validation hard.

So the proposed validation rule can be implemented (btw the turnlanes-tagging plugin even auto fixing these ways).

[skyper]

Replying to gaben:

Replying to skyper:
After reading some comments in #8519, I got a bit confused. Maybe implementing the validation on more important highways, like residential, tertiary and up is enough?

I think you do mix up "access" and "lanes".

Why do you think that? 😀

Sorry, was a wild guess as you leave out path, foot- and cycleway.

Both lanes:forward and lanes:backward where not demanded from the beginning but common practice developed to add both. So, when there are at least two lanes:* the sum should be equal to lanes. Do not forget lanes:both_ways.

Just looked up the wiki (​osmwiki:Key:lanes#Examples) and there is an example, where it says the
lanes=3
lanes:forward=1
lanes:backward=1
is a valid combination.

You forgot the "in some countries" but sadly the countries are not mentioned.

I think it shouldn't be used this way, but with lanes:both_ways because this makes the validation hard.

+1, so a discussion on tagging@ ?

So the proposed validation rule can be implemented (btw the turnlanes-tagging plugin even auto fixing these ways).

Dough, auto-fixing is really dangerous, as the tool does not know where the error/mistake was made or if there is a tag missing.

[gaben]

Replying to skyper:

I think it shouldn't be used this way, but with lanes:both_ways because this makes the validation hard.

+1, so a discussion on tagging@ ?

Can you please do it?

So the proposed validation rule can be implemented (btw the turnlanes-tagging plugin even auto fixing these ways).

Dough, auto-fixing is really dangerous, as the tool does not know where the error/mistake was made or if there is a tag missing.

It's not harmful and it does only one object at a time. Try it out :)