"n" move node onto way regression

[dieterdreist]

I just noticed that move node onto way bends the way in the opposite direction. Previously this worked fine. See attached screenshot (j is working, but n is not).

[dieterdreist]

bug in move onto way (n)

[GerdP]

I cannot reproduce this. Please upload an example *.osm file and check the used projection.

[Anton Khorev]

Happens for me when the node gets moved into several ways. The more ways get caught by the action, the greater is the bend away from the original position of the node.

[naoliv]

I saw this same problem, but it seems that it's not always reproducible.
Attaching a video and the test that I did use.

[GerdP]

I still cannot reproduce it, but I've noticed that the symbol next to the mouse cursor is different on my machine.
Yours shows either a white dot or a white line within a rectangle, in select mode my cursor shows just an empty white rectangle. I did not yet find a corresponding mapmode for this "white line in white rectangle", so I assume it is implemented in a plugin. Any ideas?

[GerdP]

Forget that, the cursor changes when you press Ctrl, probably when you use Ctrl+Z for Undo.

[dieterdreist]

@GerdP which java do you use? I was on oracle and recently switched to Openjdk

[GerdP]

I tried on two different machines, the status report on my PC shows

Build-Date:2019-10-02 08:35:58
Revision:15401
Is-Local-Build:true

Identification: JOSM/1.5 (15401 SVN en) Windows 10 64-Bit
OS Build number: Windows 10 Home 1903 (18362)
Memory Usage: 732 MB / 1753 MB (191 MB allocated, but free)
Java version: 1.8.0_191-b12, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: \Display0 1920x1080
Maximum Screen Size: 1920x1080
VM arguments: [-agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:63446, -ea, -Dfile.encoding=UTF-8]
Program arguments: [--debug]
Dataset consistency test: No problems found

Plugins:
+ OpeningHoursEditor (34977)
+ apache-commons (35092)
+ buildings_tools (34982)
+ continuosDownload (82)
+ ejml (35122)
+ geotools (35154)
+ jaxb (35014)
+ jts (35122)
+ o5m (34908)
+ opendata (35156)
+ pbf (35033)
+ poly (34991)
+ reverter (35084)
+ undelete (34977)
+ utilsplugin2 (35098)

[GerdP]

My Laptop shows

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2019-09-29 23:59:43 +0200 (Sun, 29 Sep 2019)
Build-Date:2019-09-29 22:01:37
Revision:15390
Relative:URL: ^/trunk

Identification: JOSM/1.5 (15390 en) Windows 10 64-Bit
OS Build number: Windows 10 Home 1903 (18362)
Memory Usage: 555 MB / 1820 MB (256 MB allocated, but free)
Java version: 1.8.0_212-b03, AdoptOpenJDK, OpenJDK 64-Bit Server VM
Screen: \Display0 1920x1080
Maximum Screen Size: 1920x1080
Dataset consistency test: No problems found

Plugins:
+ apache-commons (35092)
+ buildings_tools (34982)
+ ejml (35122)
+ geojson (124)
+ geotools (35154)
+ jaxb (35014)
+ jts (35122)
+ measurement (35051)
+ o5m (34908)
+ opendata (35156)
+ pbf (35033)
+ poly (34991)
+ reltoolbox (34977)
+ reverter (35084)
+ undelete (34977)
+ utilsplugin2 (35098)

and both work fine.

[GerdP]

Please attach you status reports. If you cannot reproduce this with an older JOSM version please let me know the latest version that worked fine. It might depend on the OS or the Java VM or the screen resolution.

[naoliv]

Mine is:

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2019-10-01 09:31:13 +0200 (Tue, 01 Oct 2019)
Revision:15401
Build-Date:2019-10-02 01:30:51
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (15401 pt_BR) Linux Debian GNU/Linux bullseye/sid
Memory Usage: 275 MB / 2048 MB (141 MB allocated, but free)
Java version: 13+33-Debian-1, Debian, OpenJDK 64-Bit Server VM
Screen: :0.0 1920x1080
Maximum Screen Size: 1920x1080
Java ATK Wrapper package: libatk-wrapper-java:all-0.36.0-1
libcommons-compress-java: libcommons-compress-java:all-1.18-3
libcommons-logging-java: libcommons-logging-java:all-1.2-2
VM arguments: [-Dawt.useSystemAAFontSettings=gasp]

Plugins:
+ EasyPresets (1537621333)
+ FastDraw (34977)
+ OpeningHoursEditor (34977)
+ SimplifyArea (34977)
+ apache-commons (35092)
+ buildings_tools (34982)
+ ejml (35122)
+ geojson (124)
+ geotools (35154)
+ http2 (35062)
+ jaxb (35014)
+ jogl (1.2.3)
+ jts (35122)
+ log4j (34908)
+ measurement (35051)
+ opendata (35156)
+ reverter (35084)
+ tageditor (34977)
+ tagging-preset-tester (34908)
+ todo (30306)
+ turnlanes-tagging (281)
+ turnrestrictions (34977)
+ undelete (34977)
+ utilsplugin2 (35098)
+ wikipedia (1.1.2)

But I can't always reproduce it.

[dieterdreist]

mine is

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2019-10-01 09:31:13 +0200 (Tue, 01 Oct 2019)
Revision:15401
Build-Date:2019-10-02 01:30:51
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (15401 en) Mac OS X 10.14.6
OS Build number: Mac OS X 10.14.6 (18G95)
Memory Usage: 635 MB / 2048 MB (241 MB allocated, but free)
Java version: 13+33, AdoptOpenJDK, OpenJDK 64-Bit Server VM
Screen: Display 188875520 1920x1080, Display 458628994 1920x1080
Maximum Screen Size: 1920x1080
VM arguments: [-Dsun.java2d.opengl=true]

Plugins:
+ ColorPlugin (1537115529)
+ Create_grid_of_ways (34908)
+ ImportImagePlugin (35125)
+ PicLayer (35104)
+ ShapeTools (1240)
+ apache-commons (35092)
+ buildings_tools (34982)
+ editgpx (34908)
+ ejml (35122)
+ ext_tools (34988)
+ fieldpapers (v0.5.0)
+ geochat (35163)
+ geojson (124)
+ geotools (35154)
+ imagery_offset_db (34908)
+ jts (35122)
+ log4j (34908)
+ mbtiles (v2.5.0)
+ measurement (35051)
+ o5m (34908)
+ pbf (35033)
+ photo_geotagging (34908)
+ poly (34991)
+ reltoolbox (34977)
+ reverter (35084)
+ undelete (34977)
+ utilsplugin2 (35098)

[Anton Khorev]

two ways with the same endpoints

[Anton Khorev]

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2019-09-29 23:59:43 +0200 (Sun, 29 Sep 2019)
Build-Date:2019-09-29 22:01:37
Revision:15390
Relative:URL: ^/trunk

Identification: JOSM/1.5 (15390 en) Windows 7 64-Bit
OS Build number: Windows 7 Home Basic (7601)
Memory Usage: 689 MB / 1808 MB (383 MB allocated, but free)
Java version: 1.8.0_221-b11, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: \Display0 1920x1080
Maximum Screen Size: 1920x1080
Dataset consistency test: No problems found

Plugins:
+ CommandLine (34977)
+ Create_grid_of_ways (34908)
+ ImproveWay (26)
+ PicLayer (35104)
+ alignways (34977)
+ apache-commons (35092)
+ buildings_tools (34982)
+ changeset-viewer (22)
+ ejml (35122)
+ geotools (35154)
+ graphview (34977)
+ imagery_offset_db (34908)
+ jogl (1.2.3)
+ jts (35122)
+ kendzi3d-resources (0.0.2)
+ log4j (34908)
+ reverter (35084)
+ turnrestrictions (34977)
+ undelete (34977)
+ utilsplugin2 (35098)

[GerdP]

Ah, thanks, with moveontoway.osm I can reproduce the error.

[GerdP]

OK, if I got that right the problem always occurs when the two overlapping ways are not exactly overlapping.
This is the case in Antons example.
In this case we run into rounding problems and the "move node" command is created twice. The command moves the node by adding delta values, thus the node is really moved twice when the command is executed twice.
In the example given by naoliv the nodes don't differ but the direction of the overlapping ways does. Maybe this can also cause slightly different results for the calculated position of the new node on some systems.

I am not yet sure what the expected result is when you move a node onto two different ways like in moveontocrossing.osm
I have to look at the svn log to find out more about this action...

[GerdP]

My current thinking:
The user presses N because he doesn't want to change the geoemtry of the ways to which the node(s) should be moved, so this action should not do anything if that is not possible.
So, my approach for a node and a set of multiple ways would be this
1) calculate the move command for each way (without executing it)
2) make sure that they all result in the same move command (allowing a very small delta)
2a) if they are not equal (enough), show a popup that the action cannot be performed and return without changes
2b) if they are equal, continue with the next selected node
3) create the move command(s) and the change way commands
I'll try to implement this, so let me know if you don't like that approach.

[GerdP]

Possible solution and first unit test

[GerdP]

The patch fixes the problems reported here and in #11508. It rejects the action for the example in attached moveontocrossing.osm with a popup saying

Multiple target ways, no common point found. Nothing was changed.

Please suggest a better text for this message if you have one. I'll add more unit tests for the other cases before committing this.

[GerdP]

@Vincent:
Please review the unit test. I took me a while to find out that I need the line

  MainApplication.getMap().mapView.setBounds(new Rectangle(1920, 1080));

to get reasonable results from mapView.getNearestWaySegments() in JoinNodeWayAction.actionPerformed(). Without this line the default values are nuts and the method doesn't return the segments in the expected order (ordered by perpendicular distance). I think it would be better to change this somewhere in the mocking routines.

I also do not yet understand the algo that selects the way segments. My current understanding is that it should only use the closest segment of a way but the current unpatched code will add the same node to many segments when you first zoom out so that all data is displayed in a single point. You can try with the attached test.joz.
The code could be much simpler if would only select the closest segment, but maybe there is a good reason for this?

[GerdP]

simplify algo to find the right way segment

[GerdP]

v3 shows my favorite solution. If I hear no complains I'll commit it tomorrow.

[GerdP]

In 15428/josm:

fix #18189 (18189-v3.patch)