Display problem for riverbank multipolygon

[skorbut]

What steps will reproduce the problem?

1. 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
2. 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)

[mdk]

These "artefacts" occur when a multipolygon with combined outer members is not completely loaded. More detailed: when some outer members are missing, these missing segments are replaced by strait lines connecting the end nodes of the loaded outer 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.

[GerdP]

I agree but I wonder why these "vitual closing lines" sometimes disappear when one of the open ends is visible.

[GerdP]

simple example showing the problem

[mdk]

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.

[skorbut]

Simple workaround: download incomplete members of the affected multipolygon.

Would it make sense to detect such cases and automatically download missing members?

[anonymous]

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.

[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.

Another solution could be suppress the drawing of ...

I think that's the better alternative

[mdk]

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.

[skyper]

Ticket #21252 has been marked as a duplicate of this ticket.