Opened 3 years ago
Last modified 3 years ago
#21201 new defect
Display problem for riverbank multipolygon
Reported by: | skorbut | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core mappaint | Version: | |
Keywords: | template_report incomplete multipolygon | Cc: |
Description (last modified by )
What steps will reproduce the problem?
- Download the bounding box 47.3401576,9.1186118,47.3481306,9.1361138 using JOSM -> Download Icon -> Tab: Bounding Box https://www.openstreetmap.org/#map=18/47.346514/9.127867
- Make sure the downloaded area contains the hamlets "Husen" and "Adelbach"
What is the expected result?
JOSM should display the data fine.
What happens instead?
There seems to be some kind of display artifact (a blue line going from NNW to SSE), probably induced by the partially downloaded riverbank multipolygon. The artifact is only visible in the default view right after the download and when zooming in, i.e. the artifact is not visible wheen zooming out. The artifact reappears after zooming in again. See screenshots.
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-08-05 13:43:42 +0200 (Thu, 05 Aug 2021) Revision:18125 Build-Date:2021-08-05 11:54:28 URL:https://josm.openstreetmap.de/svn/trunk Identification: JOSM/1.5 (18125 en) Linux Ubuntu 18.04.5 LTS Memory Usage: 788 MB / 7976 MB (424 MB allocated, but free) Java version: 11.0.11+9-Ubuntu-0ubuntu2.18.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 Environment variable LANG: en_US.UTF-8 System property file.encoding: UTF-8 System property sun.jnu.encoding: UTF-8 Locale info: en_US Numbers with default locale: 1234567890 -> 1234567890 Desktop environment: MATE Java package: openjdk-11-jre:amd64-11.0.11+9-0ubuntu2~18.04 Java ATK Wrapper package: libatk-wrapper-java:all-0.33.3-20ubuntu0.1 libcommons-logging-java: libcommons-logging-java:all-1.2-2 fonts-noto: fonts-noto:all-20171026-2 VM arguments: [--add-modules=java.scripting,java.sql, -Djosm.restart=true, -Djosm.dir.name=JOSM-latest, -Djava.net.useSystemProxies=true] Dataset consistency test: No problems found Plugins: + Mapillary (2.0.0-alpha.30-dirty) + apache-commons (35524) + apache-http (35589) + jna (35662)
Attachments (4)
Change History (15)
by , 3 years ago
Attachment: | broken_initial_view.png added |
---|
by , 3 years ago
Attachment: | broken_zoomed_in.png added |
---|
by , 3 years ago
Attachment: | ok_zoomed_out.png added |
---|
comment:1 by , 3 years ago
Description: | modified (diff) |
---|
comment:2 by , 3 years ago
Component: | Core → Core mappaint |
---|---|
Keywords: | incomplete multipolygon added |
comment:3 by , 3 years ago
Description: | modified (diff) |
---|
comment:4 by , 3 years ago
comment:5 by , 3 years ago
I agree but I wonder why these "vitual closing lines" sometimes disappear when one of the open ends is visible.
comment:6 by , 3 years ago
For me it looks like the "virtual closing lines" is not really shown (this should be a deep blue thin line for riverbank). But we see the implied filling of the area as a wider transparent light blue band.
It looks like the algorithm which decides where (on which side of the line) and maybe if this band should be drawn or the complete area should be filled has problems with these "virtual closing lines". If you zoom out, there is a point where the area is small enough to be filled instead of surrounded by the band. And maybe the filling of the incomplete area results in drawing nothing. This may explain the disappearing when zooming out.
follow-up: 8 comment:7 by , 3 years ago
Simple workaround: download incomplete members of the affected multipolygon.
Would it make sense to detect such cases and automatically download missing members?
comment:8 by , 3 years ago
Replying to skorbut:
Would it make sense to detect such cases and automatically download missing members?
Could be a solution. It would be enough to download missing members which are part of a closed way. The automatic downloading of ALL missing members may be expensive on large multipolygons especially when they have hundreds or thousands of of inner ways which are completely missing and producing no artifacts.
Another solution could be suppress the drawing of the "filling band" for the "virtual closing lines" as it is already done for the thin line.
follow-up: 10 comment:9 by , 3 years ago
It would be enough to download missing members which are part of a closed way
I see no way to know this before the members are downloaded.
Another solution could be suppress the drawing of ...
I think that's the better alternative
comment:10 by , 3 years ago
Replying to GerdP:
It would be enough to download missing members which are part of a closed way
I see no way to know this before the members are downloaded.
You are right. An intermediate solution could be to download all missing members with the same role as the incomplete way. This will normally the outer
members, as inner
ways are normally not split.
These "artefacts" occur when a multipolygon with combined
outer
members is not completely loaded. More detailed: when someouter
members are missing, these missing segments are replaced by strait lines connecting the end nodes of the loadedouter
members. This is the line you see. Also the detection which side of the incomplete outer path can change this way.Simple workaround: download incomplete members of the affected multipolygon.