Validator complains about "no_entry" turn restriction relation having more than one "from" member, although Wiki says this is valid use

[ingo.wohltmann@…]

What steps will reproduce the problem?

Creating a turn restriction of type "no_entry" with more than one "from" member

(e.g. relation 13956167)

What is the expected result?

No error, should be a valid restriction

What happens instead?

Validator gives error (for me, on upload)

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

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2022-04-04 22:26:00 +0200 (Mon, 04 Apr 2022)
Build-Date:2022-04-05 01:30:55
Revision:18427
Relative:URL: ^/trunk

Identification: JOSM/1.5 (18427 de) Windows 10 64-Bit
OS Build number: Windows 10 Pro 2009 (19044)
Memory Usage: 1235 MB / 3607 MB (445 MB allocated, but free)
Java version: 1.8.0_211-b12, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Look and Feel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
Screen: \Display0 1920×1080 (scaling 1.00×1.00)
Maximum Screen Size: 1920×1080
Best cursor sizes: 16×16→32×32, 32×32→32×32
System property file.encoding: Cp1252
System property sun.jnu.encoding: Cp1252
Locale info: de_DE
Numbers with default locale: 1234567890 -> 1234567890
Dataset consistency test: No problems found

Plugins:
+ Mapillary (2.0.0-beta.6-3-g192a88c)
+ PicLayer (1.0.2)
+ apache-commons (35924)
+ apache-http (35924)
+ jna (35924)
+ tageditor (35893)
+ turnlanes-tagging (v0.0.5)
+ turnrestrictions (35893)

Map paint styles:
- https://josm.openstreetmap.de/josmfile?page=Styles/SidewalksAndFootways&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Coloured_buildings&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Styles/Maxspeed&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Coloured_Streets&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Lane_and_Road_Attributes&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Lane_features&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Lane_features_ryg&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/SidewalksPlus&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Surface&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/ParkingLanes&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Cycleways&zip=1

[taylor.smock]

Closed as duplicate of #18014.
It is valid, yes. Rather unfortunately, there is not currently a way to tell a preset that there are exceptions to the rule.

I'd much rather have some false positives on no_entry/no_exit than false negatives on the other, more widely used, turn restrictions.

[skyper]

Replying to taylor.smock:

Closed as duplicate of #18014.
It is valid, yes. Rather unfortunately, there is not currently a way to tell a preset that there are exceptions to the rule.

See #20833 and #17057

[ingo.wohltmann@…]

Dear Taylor and Skyper,
I am pretty sure there is a misunderstanding here. This is about the validator, not the presets. Please see the title of my ticket, see "what happens instead" and "component: core validator". I.e., I thought this was pretty clear :-) I have the impression that could be quite easy to resolve by just adding an additional "if" clause into the source code of the validator (something like changing the code at the place that triggers the error from (in pseudo-code) "if number_of_froms>1" to "if number_of_froms>1 and not relation_type=="no_entry""). Hope this helps.

[ingo.wohltmann@…]

One addition:
Scanned through the discussion in ticket #17057. Ok, this seems to be deliberate. But I am not sure whether I can follow the arguments of user "stoecker" here (user "GerdP" was also not convinced at the beginning). This is documented in the wiki since a long time, it is used in practice, and it mostly makes sense to me (in particular for "fake" one-way streets with a sign only at one end). One could argue that "from" is not really needed, since the information what "end" of the way to use is in the "via" node, but on the other hand, it is probably used quite often in this way, and it does not hurt either. Having said this, I would also be happy to remove all "from"s from the relation. Should still work, if the routers support this...

[GerdP]

Replying to ingo.wohltmann@…:

Dear Taylor and Skyper,
I am pretty sure there is a misunderstanding here. This is about the validator, not the presets. Please see the title of my ticket, see "what happens instead" and "component: core validator". I.e., I thought this was pretty clear :-) I have the impression that could be quite easy to resolve by just adding an additional "if" clause into the source code of the validator (something like changing the code at the place that triggers the error from (in pseudo-code) "if number_of_froms>1" to "if number_of_froms>1 and not relation_type=="no_entry""). Hope this helps.

If I remember correctly the validator uses the data in the presets, so both need changes if this should be supported. I wouldn't mind if JOSM supports this, I just agreed to Dirk (stoecker) that the concept is not very good.

[taylor.smock]

Replying to GerdP:

If I remember correctly the validator uses the data in the presets, so both need changes if this should be supported. I wouldn't mind if JOSM supports this, I just agreed to Dirk (stoecker) that the concept is not very good.

You remember correctly. We do have a specific test for turn restrictions​, so we could technically carve out an exception in code (and you (GerdP) did that in r14494, which was reverted in r14501). But we would still want to modify the preset, as that is checked if the turn restriction test is disabled​.

With the following overpass query, I found 198 relations with more than one from member (no_entry) and 10 relations with more than one to member (no_exit). In short, the number of relations have not substantially changed in the three years since comment:17:ticket:17057 (127 and 13, respectively). TBH, I suspect only_ restrictions are used instead, with some probably being marked as oneways.

[out:xml][timeout:90];
(
  relation["type"="restriction"]["restriction"="no_entry"];
  relation["type"="restriction"]["restriction"="no_exit"];
);
(._;>;);
out meta;