#20455 closed enhancement (fixed)
Raise "Unclosed way - landuse" warnings to errors
Reported by: | mkoniecz | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | 21.02 |
Component: | Core validator | Version: | |
Keywords: | template_report | Cc: |
Description
What steps will reproduce the problem?
- Create unclosed
landuse=grass
way - Run validator
What is the expected result?
I get error, as it is a clear mistake that may lead to confusing data loss.
What happens instead?
I get warning.
Please provide any additional information below. Attach a screenshot if possible.
Relative:URL: ^/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2021-01-21 23:33:21 +0100 (Thu, 21 Jan 2021) Revision:17474 Build-Date:2021-01-22 02:30:49 URL:https://josm.openstreetmap.de/svn/trunk Identification: JOSM/1.5 (17474 en) Linux Ubuntu 20.04.2 LTS Memory Usage: 2104 MB / 3974 MB (235 MB allocated, but free) Java version: 11.0.9.1+1-Ubuntu-0ubuntu1.20.04, Ubuntu, OpenJDK 64-Bit Server VM Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel Screen: :0.0 1920×1080 (scaling 1.00×1.00) Maximum Screen Size: 1920×1080 Best cursor sizes: 16×16→16×16, 32×32→32×32 Desktop environment: LXQt Java package: openjdk-11-jre:amd64-11.0.9.1+1-0ubuntu1~20.04 Java ATK Wrapper package: libatk-wrapper-java:all-0.37.1-1 Environment variable LANG: en_US.UTF-8 libcommons-logging-java: libcommons-logging-java:all-1.2-2 fonts-noto: fonts-noto:- Dataset consistency test: No problems found Plugins: + buildings_tools (35669) + reverter (35688) + todo (30306) Validator rules: + https://josm.openstreetmap.de/josmfile?page=Rules/OSMLint&zip=1 + ${HOME}/Documents/install_moje/OSM software/manual editing and discussions/josm/resources/data/validator/deprecated.mapcss Last errors/warnings: - 00836.295 W: java.net.SocketException: Unexpected end of file from server. Cause: java.net.SocketException: Unexpected end of file from server - 00891.651 W: java.net.SocketException: Unexpected end of file from server. Cause: java.net.SocketException: Unexpected end of file from server - 00925.747 W: java.net.SocketException: Unexpected end of file from server. Cause: java.net.SocketException: Unexpected end of file from server - 00931.892 W: java.net.SocketException: Unexpected end of file from server. Cause: java.net.SocketException: Unexpected end of file from server - 00941.583 W: java.net.SocketException: Unexpected end of file from server. Cause: java.net.SocketException: Unexpected end of file from server - 01009.990 W: java.net.SocketException: Unexpected end of file from server. Cause: java.net.SocketException: Unexpected end of file from server - 01010.570 W: java.net.SocketException: Connection reset. Cause: java.net.SocketException: Connection reset - 01128.302 W: java.net.SocketException: Unexpected end of file from server. Cause: java.net.SocketException: Unexpected end of file from server - 01134.416 W: java.net.SocketException: Unexpected end of file from server. Cause: java.net.SocketException: Unexpected end of file from server - 01136.863 W: java.net.SocketException: Unexpected end of file from server. Cause: java.net.SocketException: Unexpected end of file from server
Attachments (1)
Change History (17)
comment:1 Changed 5 weeks ago by
comment:2 Changed 5 weeks ago by
Summary: | Raise "Unclosed way - landuse type grass" warnings to errors → Raise "Unclosed way - landuse" warnings to errors |
---|
Definitely, my title was overly specific.
comment:3 Changed 5 weeks ago by
Hmm, so far the severity is the same for all warnings produced by this test. It tests lots of tag keys. For some the result depends on the tag value, e.g. natural=*
produces if warning if the value is not one that is known to be an exception:
"arete", "bay", "cave", "cliff", "coastline", "earth_bank", "gorge", "gully", "mountain_range", "peak", "ridge", "saddle", "strait", "tree", "tree_row", "valley", "volcano"
The problem: We may show an error for a natural=xyz if I simply change the severity for all checks.
Possible solution: Show error for all those tag keys which don't have exceptions.
comment:4 Changed 4 weeks ago by
For natural I would worry about exceptions (one new linear natural tag just got proposed).
Possible solution: Show error for all those tag keys which don't have exceptions.
+1
Or maybe simply split this check in two?
comment:5 Changed 4 weeks ago by
Thought about using method OsmPrimitive.hasAreaTags()
to decide this, but that also uses an exception list for key "leisure" :(
Changed 4 weeks ago by
Attachment: | 20455.patch added |
---|
Raise warning to error for all checks when we know that the tag must describe an area
comment:6 Changed 4 weeks ago by
I am not sure why building=no is ignored in UnclosedWay
, but shop=no or landuse=no isn't. I found only 11 unclosed ways with building=no and they all look suspicious.
comment:8 Changed 4 weeks ago by
Milestone: | → 21.02 |
---|
comment:9 Changed 4 weeks ago by
Thanks! It will make easier to spot things that are definitely serious issues.
comment:11 Changed 4 weeks ago by
I think I have to lower the severity for boundary=* ways. If you download a route relation like r2554492 with members you get 10 errors "Unclosed way - boundary type administrative"
comment:14 Changed 2 weeks ago by
@Gerd Newest version of Error-Prone complains about r17491:
[javac] C:\SVN\josm\core\src\org\openstreetmap\josm\data\validation\tests\UnclosedWays.java:100: warning: [OperatorPrecedence] Use grouping parenthesis to make the operator precedence explicit [javac] if (ignore && !specialValues.isEmpty() || "boundary".equals(key)) { [javac] ^ [javac] (see https://errorprone.info/bugpattern/OperatorPrecedence) [javac] Did you mean 'if ((ignore && !specialValues.isEmpty()) || "boundary".equals(key)) {'?
I agree this is not clear, can you please make the operator precedence explicit? Not sure what is really wanted here.
comment:16 Changed 2 weeks ago by
Milestone: | 21.03 → 21.02 |
---|
I agree if we change it for all landuse=*