Modify

Opened 5 years ago

Last modified 3 years ago

#10350 new defect

[Patch] ‘Copy tags from previous selection’ uses tags from the wrong (older) selection when changing layers

Reported by: huftis Owned by: team
Priority: normal Milestone:
Component: Plugin utilsplugin2 Version:
Keywords: Cc: Don-vip, Klumbumbus

Description (last modified by simon04)

When switching between two layers, the ‘Copy tags from previous selection’ doesn’t work properly. For every selection except the first, it uses the tags from ‘one before the previous’ selection. To workaround this, one have to do an extra layer switch. Details and example below.

How to reproduce:

Open JOSM. Download the following area (or open attachment:lakes.osm).

min.lat 59.2577648
max.lat 59.2687317
min.lon 5.2319813
max.lon 5.2682877

It should contain three lakes.

Save the following text as a file named test.csv:

latitude, longitude, natural, name
59.262, 5.238, water, foo
59.261, 5.254, water, bar
59.263, 5.260, water, baz

Open ‘test.csv’ in JOSM (using opendata plugin) – or open attachment:names.osm. Press OK to import it. You will now have two layers, the OSM data layer and the ‘test.csv’ layer. The latter contains names (not real names) of three lakes in the OSM data. The goal is to copy these names to the lakes, so we do the following:

Select the leftmost point, named ‘foo’. Change the active (editing) layer to the OSM layer (by clicking on the empty space to the left of ‘Data Layer 1’ in ‘Layers’ panel). Select the leftmost lake. Press ‘Shift + R’. The tags are correctly copied, and the lake is now named ‘foo’.

Now try to repeat this type of operation. Change the layer to ‘test.csv’. Click the ‘bar’ point. Change the layer back. Click the second lake. Press ‘Shift + R’. Note that the tags of the ‘foo’ object, not the the ’bar’ object, is copied. This is a bug. Now change the layer to ‘test.csv’ and then back again (without doing anything else). Try ‘Shift + R’ again. Now the tags from ‘bar’ object is correctly copied.

To summarise:

  1. For the first object, everything works OK.
  2. For any later object, the following operations uses data for the second to last selected object, instead of from the last selected object.

a) Change layer.
b) Select source object.
c) Change layer back.
d) Select target object.
e) Press ‘Shift + R’.
f) Observe that the wrong tags have been copied.

  1. If one after step d) changes the layer and immediately change it back again, the correct tags are copied in step e).

Attachments (4)

lakes.osm (18.4 KB) - added by simon04 4 years ago.
names.osm (499 bytes) - added by simon04 4 years ago.
10350.core.patch (962 bytes) - added by simon04 4 years ago.
10350.plugin.patch (879 bytes) - added by simon04 4 years ago.

Download all attachments as: .zip

Change History (10)

Changed 4 years ago by simon04

Attachment: lakes.osm added

Changed 4 years ago by simon04

Attachment: names.osm added

comment:1 Changed 4 years ago by simon04

Description: modified (diff)

(Simplify instructions)

comment:2 Changed 4 years ago by simon04

I can reproduce. By changing the layer, you are virtually changing the selection as well. So in step 2c) you "click" on the first layer. And in step 2e) you obtain its tags.

To avoid this, you'd have to unselect the first lake before performing 2a).

Changed 4 years ago by simon04

Attachment: 10350.core.patch added

Changed 4 years ago by simon04

Attachment: 10350.plugin.patch added

comment:3 Changed 4 years ago by simon04

Cc: Don-vip added
Summary: ‘Copy tags from previous selection’ uses tags from the wrong (older) selection when changing layers[Patch] ‘Copy tags from previous selection’ uses tags from the wrong (older) selection when changing layers

attachment:10350.core.patch and attachment:10350.plugin.patch should address this by determining whether the selection change is due to a change of the active layer.

@Don-vip: Is there a nicer way to figure that out? Should #isCalledFromLayerChange better be placed in the plugin action (after making LayerChangeAdapter a protected class)?

comment:4 Changed 4 years ago by Don-vip

This is kind of a hack, I would prefer to see it in the plugin... I'm not sure how we can make it nicer. One risk remains if we rename the method. Maybe it would be better to use Class.getDeclaredMethod to have a valid reference to the method instead of just comparing its name. If we fail to find the method we can throw a proper exception instead of failing silently.

comment:5 Changed 3 years ago by simon04

In 8957/josm:

see #10350 - Allow subclasses of JosmAction access its inner classes

comment:6 Changed 3 years ago by Klumbumbus

Cc: Klumbumbus added

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set.
to The owner will be changed from team to the specified user.
The owner will change to huftis
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket
The owner will be changed from team to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.