[PATCH] JOSM validator shouldn't issue a warning for a tag level=n-m

[georges.dutreix@…]

What steps will reproduce the problem?

1. Add a tag "level=0-2" or "level=-2--1" on a staircase way.

What is the expected result?

According to Simple indoor tagging, this tag is ok and describes a staircase spaning multiple levels.

​https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging#Modelling_connections_between_different_levels

What happens instead?

Josm warns about the value and says that it should be numeric.

Please provide any additional information below.

Perhaps JOSM team doesn't want to support the simple indoor tagging scheme, I don't know. In this case it would be nice to write it in the wiki. Otherwise, the validator should accept the syntaxe level=n-m with n and m either positive or negative.

Thank you.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2022-05-29 21:53:52 +0200 (Sun, 29 May 2022)
Revision:18463
Build-Date:2022-05-30 01:30:57
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (18463 fr) Linux Debian GNU/Linux 11 (bullseye)
Memory Usage: 1016 MB / 8192 MB (598 MB allocated, but free)
Java version: 11.0.16+8-post-Debian-1deb11u1, Debian, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 1920×1080 (scaling 1.00×1.00) :0.1 1600×1200 (scaling 1.00×1.00)
Maximum Screen Size: 1920×1200
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: fr_FR.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: fr_FR
Numbers with default locale: 1234567890 -> 1234567890
Desktop environment: X-Cinnamon
Java package: openjdk-11-jre:amd64-11.0.16+8-1~deb11u1
Java ATK Wrapper package: libatk-wrapper-java:all-0.38.0-2+deb11u1
libcommons-logging-java: libcommons-logging-java:-
fonts-noto: fonts-noto:all-20201225-1

Plugins:
+ FastDraw (35893)
+ KartaView (397)
+ OpeningHoursEditor (35924)
+ apache-commons (36003)
+ apache-http (35924)
+ areaselector (1652822522)
+ austriaaddresshelper (1597341117)
+ buildings_tools (36011)
+ cadastre-fr (36021)
+ contourmerge (v0.1.9)
+ easypresets (1623509627)
+ ejml (35924)
+ geotools (36015)
+ jackson (36006)
+ jaxb (35952)
+ jna (36005)
+ jts (36004)
+ log4j (36007)
+ openqa (0.3.1)
+ photo_geotagging (35933)
+ reverter (36011)
+ todo (30306)
+ turnrestrictions (36011)
+ utilsplugin2 (35970)

Tagging presets:
+ <josm.userdata>/EasyPresets.xml

Map paint styles:
- https://josm.openstreetmap.de/josmfile?page=Styles/Coloured_Streets&zip=1
- <josm.userdata>/plugins/indoorhelper/resources/sit.mapcss

Validator rules:
+ https://josm.openstreetmap.de/josmfile?page=Rules/FranceSpecificRules&zip=1

Last errors/warnings:
- 00016.069 E: Impossible de trouver l'image "preference.png"

[skyper]

Validator only supports multi-values separated by semicolon for level as that's how it is documented on the ​wiki page and mentioned on the simple indoor tagging page. I think it is better to stick to the common rules for multiple values instead of a special rule for some tags.

[taylor.smock]

I mostly concur. The one problem with using ; with single values is when you have something that spans multiple levels (stairs) and a rather tall building (let us say 100 levels), so the stairs would have level=0;1;2;3;4;...;98;99, while using the - to indicate range shortens it to level=0-99. From a parsing standpoint, -1--2 is kind of hard and would require parsers to do some gymnastics to figure out what is going on (they cannot just do a split on -, since the split implementation might swallow the extra -, and just give the user [1, 2] instead of [-1, -2]). Probably something like (-?\d+)-(-?\d+) would work as a parsing regex and the user could then extract the groups, but I rather suspect most downstream users are just going to do the split.

Honestly, if I was writing the specification for level crossing multiple levels, I would have used the [] interval syntax from mathematics (there is an ISO standard for that), especially for something that most people are going to have to look up to know about.

[skyper]

Right, with 100 levels the value would be above the limit of characters (255).

[skyper]

Ticket #22564 has been marked as a duplicate of this ticket.

[tordanik]

I've attached a patch to fix this issue.

To do this, I've split validation of building:levels and level into different rules, as their set of valid values looks quite different. I've also added a small number of new test cases.

[stoecker]

Milestone renamed

[Famlam]

@tordanik
A little bit of feedback on the patch:

this doesn't only allow for:
level=1, level=1-2, level=-2--1
etc, but also for:
level=--------5-------------4
due to the use of -* rather than -? in the regex

[tordanik]

@Famlam: Thanks for the feedback! But note that the use of -* wasn't introduced by the patch: The unpatched version of the validation rule already allows level=--------5.

If it is preferred that I fix that issue at the same time, though, I've prepared an alternative patch which also prevents extra minus signs.

[stoecker]

I think an assertNoMatch for a -x--y (and also x--y - does this happen 0--1?) is missing.

[tordanik]

You're right, those cases are worth including. I'm providing an updated "v3" patch with extra asserts.
Note that I would not object if you added or removed these yourself in case that's less work for you than a roundtrip back to me.

Regarding the aside: Ranges in descending order do exist in the database, although (according to a quick analysis) they represent less than 2% of level values with a range in Europe – the others are ascending, i.e. list the lower value first. I would personally always choose ascending order, but as there is no clear guidance in the documentation, I'd treat them as acceptable for the moment.

[stoecker]

Replying to tordanik:

Note that I would not object if you added or removed these yourself in case that's less work for you than a roundtrip back to me.

ATM I have nearly no time to spend for JOSM, I only review tickets and keep everything running. So I appreciate anything someone else does :-)

That's also the reason why I skipped two releases this year already.