render bug with ways, strange lines (WAS: render bug with selected way)

[skyper]

I get a huge render bug when selecting all members of a national road (Bundesstraße) in low zoom level. If I zoom in it is better but still some errors.
I attach a osm-file and a screenshot

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2011-03-03 02:31:30
Last Changed Author: bastiK
Revision: 3948
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2011-03-02 19:03:33 +0100 (Wed, 02 Mar 2011)
Last Changed Rev: 3948

Identification: JOSM/1.5 (3948 en)
Memory Usage: 60 MB / 241 MB (19 MB allocated, but free)
Java version: 1.6.0_18, Sun Microsystems Inc., OpenJDK Client VM
Operating system: Linux
Dataset consistency test: No problems found

Plugin: cadastre-fr (25192)
Plugin: utilsplugin2 (25190)

[skyper]

osm

[skyper]

screenshot

[skyper]

screenshot 2

[skyper]

looks like this

[bastiK]

Cannot reproduce.

There is probably some setting that triggers the bug. Try to start with fresh configuration

java -Djosm.home=$HOME/.josm-new -jar josm-latest.jar

[skyper]

Replying to bastiK:

Cannot reproduce.

There is probably some setting that triggers the bug. Try to start with fresh configuration

java -Djosm.home=$HOME/.josm-new -jar josm-latest.jar

I check on Ubuntu 10.10 and everything was fine but for the Debian squeeze it did not help. I also totally reinstalled open-jdk, but nothing different

Build-Date: 2011-03-07 02:31:27
Last Changed Author: mjulius
Revision: 3961
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2011-03-06 22:06:57 +0100 (Sun, 06 Mar 2011)
Last Changed Rev: 3961

Identification: JOSM/1.5 (3961 de)
Memory Usage: 36 MB / 367 MB (11 MB allocated, but free)
Java version: 1.6.0_18, Sun Microsystems Inc., OpenJDK Client VM
Operating system: Linux
Dataset consistency test: No problems found

[bastiK]

Please add more information that could help to diagnose the problem. Does it happen on all ways, all the time, etc.

Try draw.segment.head_only=false. Is it still the same?

[skyper]

Replying to bastiK:

Please add more information that could help to diagnose the problem. Does it happen on all ways, all the time, etc.

It happens on many ways (but sometimes you have to zoom way out). I just tried it with a new way with only 2 nodes and no tags.

Try draw.segment.head_only=false. Is it still the same?

yes

[skyper]

Sorry, seems to happen with all ways.
It happens with only one way selected and it does not matter if the way is closed or not.

the bug was introduced between r3888 and r3891. It works with r3887.

Hope that helps.

[bastiK]

Replying to skyper:

Replying to bastiK:

Please add more information that could help to diagnose the problem. Does it happen on all ways, all the time, etc.

It happens on many ways (but sometimes you have to zoom way out). I just tried it with a new way with only 2 nodes and no tags.

Try draw.segment.head_only=false. Is it still the same?

yes

You get a line with one arrow when selected, but still there is a line to (0,0) for each node? That would be surprising...

[bastiK]

Replying to skyper:

Sorry, seems to happen with all ways.
It happens with only one way selected and it does not matter if the way is closed or not.

the bug was introduced between r3888 and r3891. It works with r3887.

That's helpful, probably [3889]; note to self: The trigger could be omitted rounding for the arrow coordinates or

g.setStroke(new BasicStroke(line.getLineWidth(), line.getEndCap(), BasicStroke.JOIN_MITER, line.getMiterLimit()));

before drawing the arrows.

Hope that helps.

It's hard to investigate on a platform where the bug does not occur. [3889] looks fine to me, so basically this is all I can do at the moment. If you are into it, you could try to debug yourself.

[skyper]

Replying to bastiK:

Replying to skyper:

Replying to bastiK:

Please add more information that could help to diagnose the problem. Does it happen on all ways, all the time, etc.

It happens on many ways (but sometimes you have to zoom way out). I just tried it with a new way with only 2 nodes and no tags.

Try draw.segment.head_only=false. Is it still the same?

yes

You get a line with one arrow when selected, but still there is a line to (0,0) for each node? That would be surprising...

No I get an extra line from last node to (0,0).

The lines do appear one by one zooming out when several ways are selected. It is easy to miss with only one or two ways seleccted because you have to zoom way out.

[skyper]

Now I have the same issue on another system (ubuntu)

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2011-03-20 02:31:26
Last Changed Author: mjulius
Revision: 3995
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2011-03-20 01:29:48 +0100 (Sun, 20 Mar 2011)
Last Changed Rev: 3995

Identification: JOSM/1.5 (3995 en)
Memory Usage: 642 MB / 1820 MB (240 MB allocated, but free)
Java version: 1.6.0_20, Sun Microsystems Inc., OpenJDK 64-Bit Server VM
Operating system: Linux
Dataset consistency test: No problems found

Plugin: ColumbusCSV (25192)
Plugin: cadastre-fr (25192)
Plugin: colorscheme (25192)
Plugin: openstreetbugs (25540)
Plugin: public_transport (25192)
Plugin: tageditor (25191)
Plugin: toms (23605)
Plugin: undelete (25199)
Plugin: wms-turbo-challenge2 (25191)

This time it happens even with unselected closed ways (forest)

[bastiK]

If you can compile josm yourself, you can do a partial revert of [3889] and see what happens.

[rab]

Same problem here with Mandriva 10.2 64 bit.
First the error occured only with selected ways.
Now all the ways are affected.
Handling is also significantly slower.
On my laptop with Mandriva i586, JOSM performes completly normal.

[skyper]

Changed title as the problem appears even with unselected ways.

[skyper]

Now it gets even into data.

If I delete the node in the north (which is faulty) I get a way with 5 nodes as one node is still listed twice:

if I cut the way where the line goes of I get a way containing twice the same node:

I attach all three osm-files.

[anonymous]

osm 1

[anonymous]

osm 2

[anonymous]

osm 3

[anonymous]

screenshot 1

[anonymous]

screenshot 2

[anonymous]

screenshot 3

[bastiK]

this is completely unrelated

[bastiK]

Please check if it is gone with [4042].

For the second bug, it looks interesting, please open another ticket.

[skyper]

Replying to bastiK:

Please check if it is gone with [4042].

Yes, thanks a lot.
I check just one example, so far but this one works with r4054 and it did not with r4041.

For the second bug, it looks interesting, please open another ticket.

I did: #6234