Modify

Opened 4 months ago

Closed 4 months 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:

Description

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
Revision:14478
Is-Local-Build:true

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

Plugins:
+ 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 4 months ago.

Download all attachments as: .zip

Change History (22)

Changed 4 months ago by GerdP

Attachment: sample.osm added

comment:1 Changed 4 months ago by GerdP

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

comment:2 Changed 4 months ago by GerdP

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 Changed 4 months ago by stoecker

Resolution: fixed
Status: closedreopened

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

comment:4 Changed 4 months ago by GerdP

comment:5 Changed 4 months ago by stoecker

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

https://wiki.openstreetmap.org/w/index.php?title=Relation:restriction&diff=1023151&oldid=981713

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 Changed 4 months ago by stoecker

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 Changed 4 months ago by GerdP

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 https://forum.openstreetmap.org/viewtopic.php?id=64656

comment:8 Changed 4 months ago by stoecker

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 Changed 4 months ago by GerdP

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 Changed 4 months ago by stoecker

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 Changed 4 months ago by GerdP

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 Changed 4 months ago by stoecker

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

comment:13 Changed 4 months ago by GerdP

comment:15 Changed 4 months ago by stoecker

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 Changed 4 months ago by Klumbumbus

;)

comment:17 Changed 4 months ago by GerdP

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 Changed 4 months ago by stoecker

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 Changed 4 months ago by GerdP

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 Changed 4 months ago by GerdP

In 14501/josm:

see #17057 : revert changes from r14494

comment:21 Changed 4 months ago by GerdP

Resolution: wontfix
Status: reopenedclosed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.