Modify

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 GerdP)

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)

Attachments (4)

broken_initial_view.png (363.6 KB ) - added by skorbut 3 years ago.
broken_zoomed_in.png (211.1 KB ) - added by skorbut 3 years ago.
ok_zoomed_out.png (396.6 KB ) - added by skorbut 3 years ago.
21201-sample.osm (1.2 KB ) - added by GerdP 3 years ago.
simple example showing the problem

Download all attachments as: .zip

Change History (15)

by skorbut, 3 years ago

Attachment: broken_initial_view.png added

by skorbut, 3 years ago

Attachment: broken_zoomed_in.png added

by skorbut, 3 years ago

Attachment: ok_zoomed_out.png added

comment:1 by skorbut, 3 years ago

Description: modified (diff)

comment:2 by skyper, 3 years ago

Component: CoreCore mappaint
Keywords: incomplete multipolygon added

comment:3 by GerdP, 3 years ago

Description: modified (diff)

comment:4 by mdk, 3 years ago

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.

comment:5 by GerdP, 3 years ago

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

by GerdP, 3 years ago

Attachment: 21201-sample.osm added

simple example showing the problem

comment:6 by mdk, 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.

comment:7 by skorbut, 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?

in reply to:  7 comment:8 by anonymous, 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.

comment:9 by GerdP, 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

in reply to:  9 comment:10 by mdk, 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.

comment:11 by skyper, 3 years ago

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from team to the specified user.
Next status will be 'needinfo'. The owner will be changed from team to skorbut.
as duplicate The resolution will be set to duplicate. Next status will be 'closed'. The specified ticket will be cross-referenced with this ticket.
The owner will be changed from team to anonymous. Next status will be 'assigned'.

Add Comment


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