Incorrect understanding of lanes=* and *:lanes=* damages data

[skyper]

What steps will reproduce the problem?

1. Have a way with a cycle lane and complete :lanes-tagging, e.g. ​w328843875.

   access:lanes=yes|yes|yes|no|yes
   bicycle:lanes=yes|yes|yes|designated|yes
   change:lanes=|||no|no
   cycleway:right=lane
   destination:symbol:lanes=|motorway|motorway||
   highway=primary
   lanes=4
   name=Schreiberstraße
   oneway=yes
   placement=right_of:2
   sidewalk=right
   turn:lanes=left|through|through|through|right
   width:lanes=|||1.8|
   

2. Open Turn-Lane-tagging-Editor
3. Close Dialog with OK without changing anything.

What is the expected result?

No changes

What happens instead?

The value of lanes is raised by one.

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

The assumption that lanes[:forward/:backward/:both_ways]=* is always equal to the number of *:lanes[:forward/:backward/:both_ways]=* values is incorrect. It is rather equal or more.
Please take a look at the core validator rules (lanes.java) and #17172.
Additional, to cycle lanes, more :lanes not counting for lanes=* could be present, therefore please, do not rely on bicycle:lanes=*

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2021-11-01 23:05:46 +0100 (Mon, 01 Nov 2021)
Revision:18303
Build-Date:2021-11-01 22:25:18
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (18303 en) Linux Debian GNU/Linux 11 (bullseye)
Java version: 17.0.1+12-Debian-1deb11u2, Debian, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Environment variable LANG: en_US.utf8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: en_US
Numbers with default locale: 1234567890 -> 1234567890
Desktop environment: GNOME
libcommons-compress-java: libcommons-compress-java:all-1.20-1
libcommons-logging-java: libcommons-logging-java:all-1.2-2
fonts-noto: fonts-noto:all-20201225-1
VM arguments: [-Djosm.home=<josm.pref>]
Dataset consistency test: No problems found

Plugins:
+ tageditor (35640)
+ turnlanes-tagging (288)

Map paint styles:
+ https://josm.openstreetmap.de/josmfile?page=Styles/Lane_and_Road_Attributes&zip=1

[BalooUriza]

Recommend closing this as not a bug; seems more like the wiki is inconsistent, not the lane counts produced.

[1ec5]

Replying to BalooUriza:

Recommend closing this as not a bug; seems more like the wiki is inconsistent, not the lane counts produced.

That would be rather premature, given ​the ongoing forum discussion that is awaiting more information to support your perspective.

[BalooUriza]

I don't appreciate the harassment, 1ec5, and appreciate it if you would stop contacting me.

[skyper]

Replying to BalooUriza:

Recommend closing this as not a bug; seems more like the wiki is inconsistent, not the lane counts produced.

Rather the opposite is true. The definition and the wiki are consistent since a decade and longer but the plugin never followed the definition.

As there was no reaction for almost two years, now, I vote to disable/deprecate the plugin as it still damages correctly tagged ways and introduces incorrect data.

[BalooUriza]

The plugin does follow the more obvious definition of lanes that *:lanes=* uses, and most other software makes the same assumption. There's not really a good reason to try to keep claiming that standardizing the definition of a lane is a bad thing just because the wiki says to use an especially carbrained version of what a lane is that doesn't agree with *:lanes=* usage.

Let's keep the plugin how it is, it's fine. The wiki's lanes page is outdated and should be updated to match the definition of a lane according to the *:lanes=* tag since that's already the definition used in practice by most software and by this plugin.