Opened 6 years ago

Closed 6 years ago

#17057 closed defect (wontfix)

Validator should not complain about restriction=no_entry relation

Reported by: GerdP Owned by: team
Priority: normal Milestone:
Component: Core validator Version:
Keywords: template_report Cc:


What steps will reproduce the problem?

  1. Run Validator on attached sample.osm

What is the expected result?

No warning or error for relation 8124921

What happens instead?

Errors (1)
More than one "from" way found (1)
Warnings (1)
Role verification problem - Number of 'from' roles too high (2) (1)

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

Build-Date:2018-12-01 19:52:23

Identification: JOSM/1.5 (14478 SVN en) Windows 10 64-Bit
OS Build number: Windows 10 Home 1803 (17134)
Memory Usage: 1726 MB / 5461 MB (1066 MB allocated, but free)
Java version: 1.8.0_191-b12, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: \Display0 1920x1080
Maximum Screen Size: 1920x1080
Dataset consistency test: No problems found

+ FastDraw (34510)
+ apache-commons (34506)
+ buildings_tools (34724)
+ download_along (34503)
+ editgpx (34751)
+ ejml (34389)
+ geotools (34513)
+ gpxfilter (34506)
+ jaxb (34506)
+ jts (34524)
+ measurement (34529)
+ o5m (34405)
+ opendata (34698)
+ pbf (34576)
+ poly (34546)
+ reltoolbox (34614)
+ reverter (34552)
+ utilsplugin2 (34506)

Last errors/warnings:
- W: Update plugins - org.openstreetmap.josm.plugins.PluginHandler$UpdatePluginsMessagePanel[,0,0,0x0,invalid,layout=java.awt.GridBagLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
- W: No configuration settings found.  Using hardcoded default values for all pools.

Attachments (1)

sample.osm (319.4 KB ) - added by GerdP 6 years ago.

Download all attachments as: .zip

Change History (22)

by GerdP, 6 years ago

Attachment: sample.osm added

comment:1 by GerdP, 6 years ago

Summary: Validator should not complain about restriction=no_enty relationValidator should not complain about restriction=no_entry relation

comment:2 by GerdP, 6 years ago

Resolution: fixed
Status: newclosed

In 14494/josm:

fix #17057

  • Allow multiple from ways in no_entry turn restriction
  • Allow multiple to ways in no_exit turn restriction
  • Don't check turn restrictions in RelationChecker when TurnrestrictionTest is enabled

comment:3 by stoecker, 6 years ago

Resolution: fixed
Status: closedreopened

Hmm, that violates the generic turn restriction idea. I don't think that's a good idea.

comment:5 by stoecker, 6 years ago

Somebody unknown changed the wiki and added that incompatible change and it seems nobody noticed it:

That modification is not justified by the implementation and the idea of restrictions. JOSM does not support such restrictions as far as I known and probably also no other tools.

comment:6 by stoecker, 6 years ago

We should check if routing engines support that behaviour or not. If not the wiki should be fixed. If they do, we need to implement it in JOSM as well (i.e. the map display of routing restrictions, the restriction preset and probably some other places. E.g. How does turnrestrictions plugin handle these?

comment:7 by GerdP, 6 years ago

OK, I only know them because I've implemented support for mkgmap years ago.
At that time it was rarely used but I think the argument is that you use one object for one feature.
See also

comment:8 by stoecker, 6 years ago

The rationale is clear, but this restriction relation was designed in a way that you only need to know if it is "no" or "only". This change requires that different types need different behaviour.

comment:9 by GerdP, 6 years ago

Yes, it makes things less easy. Same problem as with multiple via ways. My understanding is that JOSM should not complain when it is accepted. Another point is whether it supports the creation with presets etc.
If you don't like it at all I can revert the change. I just thought it was forgotton to implement it.

comment:10 by stoecker, 6 years ago

It is not that easy. Even if the change was unjustified, we can't simply ignore 4 years documented behaviour. We need to do a 'market research'.

comment:11 by GerdP, 6 years ago

A few minutes ago it was implemented in brouter, also because of the discussion in the german forum.
According to this post OSRM uses only the last from way and Graphhopper ignores all turn restrictions.

comment:12 by stoecker, 6 years ago

Does anybody know an easy way to get the number of existing relations of this type?

comment:15 by stoecker, 6 years ago

Sorry to be unclear: Affected are only these with more than one to and from. For a simple taginfo I woudn't have asked :-)

comment:16 by Klumbumbus, 6 years ago


comment:17 by GerdP, 6 years ago

You can download them with the overpass api and use search type:relation ways:3-
I find 127 no_entry rels and only 13 no_exit rels with more then 2 ways.

comment:18 by stoecker, 6 years ago

Hmm. ATM my suggestion would be:

  • revert this change here
  • revert the wiki edit with an appropriate notice

140 relations are simply nothing compared to 1 million restriction relations.

comment:19 by GerdP, 6 years ago

After thinking this over again I no longer like the two types no_entry and no_exit at all. The concept seems broken. I see no need for a "from" role in a no_entry restriction, vice versa there I see no need for a "to" role in a no_exit restriction.

comment:20 by GerdP, 6 years ago

In 14501/josm:

see #17057 : revert changes from r14494

comment:21 by GerdP, 6 years ago

Resolution: wontfix
Status: reopenedclosed

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.