Modify

Opened 3 years ago

Closed 3 years ago

#13385 closed defect (fixed)

[Patch] rendering artifacts

Reported by: GerdP Owned by: team
Priority: normal Milestone: 16.08
Component: Core mappaint Version:
Keywords: template_report gsoc-core regression Cc: michael2402, Klumbumbus

Description (last modified by Don-vip)

What steps will reproduce the problem?

  1. load attached y.osm.bz
  2. zoom out (press "-" key three or more times)

What is the expected result?

no artifacts (blue lines which don't exist in the OSM data) when zooming out

What happens instead?

The more you zoom out the more artifacts appear. I don't see this with 10786.

Please provide any additional information below. Attach a screenshot if possible.

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-08-19 02:40:50 +0200 (Fri, 19 Aug 2016)
Build-Date:2016-08-19 01:35:35
Revision:10852
Relative:URL: ^/trunk

Identification: JOSM/1.5 (10852 en) Windows 10 64-Bit
Memory Usage: 4821 MB / 5461 MB (4510 MB allocated, but free)
Java version: 1.8.0_102-b14, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
VM arguments: [-Dsun.java2d.opengl=true]
Dataset consistency test: No problems found

Plugins:
+ apache-commons (32699)
+ buildings_tools (32796)
+ ejml (32680)
+ geotools (32813)
+ jts (32699)
+ o5m (32837)
+ opendata (32811)
+ pbf (32699)
+ poly (32699)
+ reverter (32796)
+ utilsplugin2 (32815)


Attachments (7)

y.osm.bz2 (3.5 MB) - added by GerdP 3 years ago.
screenshot.jpg (751.9 KB) - added by GerdP 3 years ago.
13385-1.png (12.6 KB) - added by michael2402 3 years ago.
13385-2.png (11.7 KB) - added by michael2402 3 years ago.
13385-3.png (7.2 KB) - added by michael2402 3 years ago.
13385.patch (5.8 KB) - added by GerdP 3 years ago.
josm_13385_high_zoom_artifact.screen.png (58.3 KB) - added by skyper 3 years ago.
screenshot high zoom

Change History (28)

Changed 3 years ago by GerdP

Attachment: y.osm.bz2 added

Changed 3 years ago by GerdP

Attachment: screenshot.jpg added

comment:1 Changed 3 years ago by Don-vip

Description: modified (diff)

comment:2 Changed 3 years ago by Don-vip

Cc: michael2402 added
Keywords: gsoc-core regression added
Milestone: 16.08

comment:3 Changed 3 years ago by Don-vip

I don't know what's causing this, but it's beautiful! I have never seen Ireland so shiny.

Changed 3 years ago by michael2402

Attachment: 13385-1.png added

Changed 3 years ago by michael2402

Attachment: 13385-2.png added

Changed 3 years ago by michael2402

Attachment: 13385-3.png added

comment:4 Changed 3 years ago by michael2402


The problem is the OffsetIterator: Now that the coordinates are exact, such sharp corners were not ignored any more. You can notice it on lower zoom levels. I'll have a look at it tomorrow.

comment:5 Changed 3 years ago by Klumbumbus

Cc: Klumbumbus added

comment:6 Changed 3 years ago by GerdP

@michael2402: I am not sure, but I think the offset that is used in OffsetIterator should be scaled.
This will solve the problem when zooming out, as the offset is getting close to 0.

        OffsetIterator(List<Node> nodes, double offset) {
            this.nodes = nodes;
            this.offset = offset / mapState.getScale();
            idx = 0;
        }
Last edited 3 years ago by Don-vip (previous) (diff)

comment:7 Changed 3 years ago by GerdP

or better

this.offset = Math.max(offset, offset / mapState.getScale());

to avoid problems when zooming in.

Last edited 3 years ago by Don-vip (previous) (diff)

comment:8 Changed 3 years ago by michael2402

No, this should not be done.

This value comes from the MapCSS offset property. The style will set it to half the line width to draw a line on the inner side of the border. The problem is that the offset iterator does not handle the line cap correctly. Implementing this is not hard, just some case work - which I have not found time to do yet.

A quick fix would be to restrict the deltax/y values to e.g. offset * 4. This would simply cap the lines. A nicer solution would be to really add a line cap. We may even use bezier courves for this, it would make the road lane style look much nicer.

comment:9 Changed 3 years ago by GerdP

OK, I think I understand. The next() method just has to return more points in this case.
If you don't mind I'll try to this tomorrow.

comment:10 Changed 3 years ago by michael2402

Yes, that is all you need to do. Two points should be enough (for a flat linecup - if we want a curve, we should use Path2D.curveTo which would require a change in the interface)

You may not even need to add any special state information - you can compute the first of the two points you add and store a fake point as last so that you will return the right point in the next iteration.

If you want to, you can replace that iterator with a complete new algorithm that directly works on a Path2D. This class is only used internally, so you can handle it however you want to ;-).

Changed 3 years ago by GerdP

Attachment: 13385.patch added

comment:11 Changed 3 years ago by GerdP

I think I found a solution, see 13385.patch.
I found it quite difficult to calculate the point coordinates. I guess there are functions for this somewhere, but I don't know where to search. With the patch I see no more artifacts. I also tested with the "Lane and roads attributes" style and that also seems to profit.

Last edited 3 years ago by Don-vip (previous) (diff)

comment:12 Changed 3 years ago by simon04

Are you looking for Geometry#getSegmentSegmentIntersection?

comment:13 Changed 3 years ago by michael2402

JOSM does not really have central geometry utility functions. There are some in Geometry but a lot of useful stuff is missing there and in some tool classes instead. If you feel the need for any useful functions, simply add them there.

Your patch looks fine, thanks ;-).

comment:14 in reply to:  12 Changed 3 years ago by GerdP

Replying to simon04:

Are you looking for Geometry#getSegmentSegmentIntersection?

No, my problem was to find the rules when capping should happen and where to place the intermittend points. I assume the same
problem was already solved somewhere in the java graphics routines, maybe also in JOSM sources.

Last edited 3 years ago by Don-vip (previous) (diff)

comment:15 Changed 3 years ago by michael2402

The line capping is implemented internally in Java2D. There is no public interface for it. Same for line clipping.

comment:16 Changed 3 years ago by skyper

Summary: rendering artifacts[Patch] rendering artifacts

comment:17 Changed 3 years ago by Don-vip

Resolution: fixed
Status: newclosed

In 10887/josm:

fix #13385 - rendering artifacts (patch by Gerd Petermann)

comment:18 Changed 3 years ago by Klumbumbus

Component: CoreCore mappaint

Changed 3 years ago by skyper

screenshot high zoom

comment:19 Changed 3 years ago by skyper

Resolution: fixed
Status: closedreopened

At least for really high zoom levels (from ~0.05 metres on), I still have some offsets and artifacts. access=private seems to be a good test case.

screenshot high zoom

Could be a related to #13636

comment:20 Changed 3 years ago by Klumbumbus

Do you still have the osm file which created this artifact?

comment:21 in reply to:  20 Changed 3 years ago by skyper

Resolution: fixed
Status: reopenedclosed

Replying to Klumbumbus:

Do you still have the osm file which created this artifact?

This was not specific to one file/data set. Can still reproduce it with a access=private and highway=footway with josm-tested.jar.

With latest it is fixed. e.g. [11026] or [11027] did fix it.

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.