Node thrown to lat=0 on ungluing it from ways

[santamariense]

Hey folks,

I have faced an issue with ungluing (tagged) nodes from ways. When doing this, the node is thrown to the lat = 0 (zero) (lon stay at the correct position) and I have to zoom out and bring the node back to the spot where I am editing.

This is the first time I open a ticket here. Let me know if I am not following correctly the procedure.

Thanks in advance for fixing it.

JOSM 18583 / Linux Debian

santamariense

[taylor.smock]

Thanks for your report, however your ticket is incomplete and therefore not helpful in its current form.

Please add all needed information according to this list:

• The required parts of the Status Report from your JOSM.
  • Please, use Report Bug from Help menu and copy & paste.
• Describe what behaviour you expected.
• Describe what did happen instead.
• Describe if and how the issue is reproducible.
• Add any relevant information like error messages or screenshots.

To ensure that all technical relevant information is contained, create new tickets by clicking in JOSMs Main Menu on Help → Report Bug.

---

I haven't been able to reproduce with a tagged node connected to a way using either the Unglue Ways action (trying all three options) or Disconnect node from way.

Can you please give me steps to reproduce? Something along the lines of:

1. Select node 2391132965 (you can get this if you copy the object (ctrl+c) and then paste in the ticket)
2. Tools -> UnGlue Ways
3. Existing node
4. Unglue

[santamariense]

Thank you for sharing the step-by-step instructions. It looks to be reproducible when the node is a child of just one way. So, check below for more information.

What steps will reproduce the problem?

1. Select node #6281645316 to unglue it from way #314272361. Or, in any case when the node is a child of just one way.
2. Key "G" (or menu Tools > Unglue ways > Existing node > Unglue)

What is the expected result?

It is expected that the unglued node stays at the same position or very close.

What happens instead?

The node is thrown ~555 km in the north direction. Now I see that in my original report, it was thrown to around lat=0 by coincidence. I also tried to unglue other nodes in the same situation and no matter where I tried to do this, the unglued node moved to ~555km in the north direction.

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

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2022-10-31 17:29:20 +0100 (Mon, 31 Oct 2022)
Revision:18583
Build-Date:2022-11-01 02:30:58
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (18583 en) Linux Debian GNU/Linux 11 (bullseye)
Memory Usage: 1145 MB / 3970 MB (721 MB allocated, but free)
Java version: 11.0.16+8-post-Debian-1deb11u1, Debian, 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: GNOME
Java package: openjdk-11-jre:amd64-11.0.16+8-1~deb11u1
Java ATK Wrapper package: libatk-wrapper-java:all-0.38.0-2+deb11u1
libcommons-compress-java: libcommons-compress-java:all-1.20-1
libcommons-logging-java: libcommons-logging-java:all-1.2-2
fonts-noto: fonts-noto:all-20201225-1
VM arguments: [--module-path=/usr/share/openjfx/lib, --add-modules=java.scripting,java.sql,javafx.controls,javafx.media,javafx.swing,javafx.web, -Djosm.restart=true, -Djava.net.useSystemProxies=true, --add-exports=java.base/sun.security.action=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED]
Dataset consistency test: No problems found

Plugins:
+ FastDraw (35978)
+ Mapillary (2.0.1)
+ PicLayer (1.0.2)
+ apache-commons (36034)
+ apache-http (35924)
+ auto_tools (81)
+ buildings_tools (36011)
+ changessum (v0.1.1)
+ conflation (0.6.9)
+ easypresets (1623509627)
+ editgpx (35931)
+ ejml (35924)
+ ext_tools (35893)
+ geotools (36028)
+ gridify (1606242219)
+ imagery_offset_db (35978)
+ jackson (36034)
+ jaxb (35952)
+ jna (36005)
+ jts (36004)
+ measurement (35978)
+ opendata (36025)
+ poly (35976)
+ reverter (36011)
+ tageditor (36011)
+ turnlanes (36011)
+ turnlanes-tagging (v0.0.5)
+ turnrestrictions (36011)
+ undelete (36011)
+ utilsplugin2 (36011)
+ waydownloader (36011)

Tagging presets:
+ <josm.userdata>/EasyPresets.xml
+ /media/<user.name>/MyPresets/Ground Survey with Mapillary.xml


Last errors/warnings:
- 00006.809 W:  Building details: Could not get presets icon presets/empty.png
- 00006.809 E: Failed to locate image 'presets/empty.png'
- 00006.809 W:  Features at the street: Could not get presets icon presets/empty.png
- 00006.810 E: Failed to locate image 'presets/empty.png'
- 00006.810 W:  Amenitiy, office, shop, craft: Could not get presets icon presets/empty.png
- 00007.045 W: Cannot lock cache directory. Will not use disk cache
- 00008.096 W: Ext_Tools warning: can not load file <josm.userdata>/plugins/ext_tools/tools.cfg
- 00008.096 W: Ext_Tools warning: can not load file <josm.userdata>/plugins/ext_tools/repo.cfg
- 00008.321 W: Cannot start IPv4 remotecontrol server on port 8111: Address already in use (Bind failed)
- 00008.322 W: Cannot start IPv6 remotecontrol server on port 8111: Address already in use (Bind failed)

[taylor.smock]

The node is thrown ~555 km in the north direction. Now I see that in my original report, it was thrown to around lat=0 by coincidence. I also tried to unglue other nodes in the same situation and no matter where I tried to do this, the unglued node moved to ~555km in the north direction.

I'm not seeing this.
What I am seeing is that the selected node is moving to where the mouse currently is. Which is probably intended behavior. I'd have to look into the source history to be certain.

I'll see if I can reproduce on Debian. I'm guessing that the mouse is reported as being at some random, far away, position.

It might take me a bit though.

EDIT: To be clear, it is something that should be consistent -- either it should always happen with new nodes, or it should never happen. Unless there is a good reason given in the originating commit/ticket.

[skyper]

Replying to taylor.smock:

The node is thrown ~555 km in the north direction. Now I see that in my original report, it was thrown to around lat=0 by coincidence. I also tried to unglue other nodes in the same situation and no matter where I tried to do this, the unglued node moved to ~555km in the north direction.

I'm not seeing this.
What I am seeing is that the selected node is moving to where the mouse currently is. Which is probably intended behavior. I'd have to look into the source history to be certain.

Yes, the move is intended, see r16362 and #19352.

I'll see if I can reproduce on Debian. I'm guessing that the mouse is reported as being at some random, far away, position.

On a quick test, I was not able to reproduce the "far away position" on Debian with josm-latest and fresh preferences.

[santamariense]

Well, I have just created a new user on Debian to try to reproduce this behavior on a fresh JOSM. This time JOSM unglued the node from the way correctly. What would be causing that issue? Preferences or maybe an installed plugin?

[taylor.smock]

Probably something in preferences, assuming it isn't OS specific -- I wasn't able to reproduce with the given plugin list.

Unless you know what you are doing, please don't upload your preferences file -- it may contain sensitive information like your password or the oauth token for OpenStreetMap.

If you are fairly confident with a text editor (like vim or something), you can try doing a bisect on your preferences file, and see if you can figure out what preference key and value were the problem.

This is surprising behavior -- I'm not seeing anything in the code where a preference value should make a difference.