Modify

Opened 7 years ago

Closed 6 weeks ago

#9673 closed defect (wontfix)

Create Multipolygon (Ctrl-B) shuffles the ways

Reported by: karljunk Owned by: team
Priority: normal Milestone:
Component: Core Version:
Keywords: create multipolygon selection order Cc:

Description

In Version 6502, I have created a lot of multipolygons using CTRL-ALT-A, which is CTRL-B in version 6767 now. I do not mind the change of the keyboard shortcut (though such a thing should not happen too often). However, a new bug was introduced:

In Version 6502, when I created a multipolygon, the order of ways was exactly as I selected them. In Version 6767, the ways a shuffled somehow. So it is dangerous to use this function for creating multipolygons with more than 3 ways.

Minor issue: In Version 6502, the newly created multypolygon was selected in the relation list. In Version 6767, it is not selected. What I would prefer is that the tag list of the newly created relation is automatically selected, because the next thing I want to do after creating a multipolygon is always adding tags to the relation.

Another small issue: When creating a multipolygon this way, tags that are common to all member ways are transferred to the relation. This is nice. However, maybe disable the transfer for tags that make no sense when attached to a multpolygon, e.g. barrier=fence or highway=track.

Attachments (0)

Change History (15)

comment:1 Changed 7 years ago by naoliv

At least fence_type isn't moved anymore since [6765]. barrier and source too.

comment:2 Changed 7 years ago by simon04

In Version 6502, when I created a multipolygon, the order of ways was exactly as I selected them. In Version 6767, the ways a shuffled somehow. So it is dangerous to use this function for creating multipolygons with more than 3 ways.

The order of relation members shouldn't have changed in the recent versions. Could you please give a reproducible example (which worked before) to ease debugging.

comment:3 Changed 7 years ago by simon04

In 6807/josm:

see #9673 - Select newly created multipolygon in relation list (fixes regression)

comment:4 Changed 7 years ago by simon04

Another small issue: When creating a multipolygon this way, tags that are common to all member ways are transferred to the relation. This is nice. However, maybe disable the transfer for tags that make no sense when attached to a multpolygon, e.g. barrier=fence or highway=track.

It might be easier to specify a few tags that should be transferred? I guess most of the highway tags (like access, lit, …) shouldn't be transferred. On the other side, creating multipolygons out of such objects isn't very common, is it?

comment:5 in reply to:  2 Changed 7 years ago by karljunk

Replying to simon04:

In Version 6502, when I created a multipolygon, the order of ways was exactly as I selected them. In Version 6767, the ways a shuffled somehow. So it is dangerous to use this function for creating multipolygons with more than 3 ways.

The order of relation members shouldn't have changed in the recent versions. Could you please give a reproducible example (which worked before) to ease debugging.

I have created multipolygon 3487476 in northern Norway, a sea. I did first draw the shore as a polygon. Then I split the polygon with Ctrl-P in 14 different ways. Then I labeled them with way1 to way14, clockwise, starting with the way in the West of the sea. Then I selected the ways in the correct order, form 1 to 14, until all ways were selected. Then I pressed Ctrl_B.

comment:6 Changed 6 years ago by Don-vip

Summary: Create Multpolygon (Ctrl-B) shuffles the waysCreate Multipolygon (Ctrl-B) shuffles the ways

comment:7 Changed 6 months ago by skyper

Still the same issue. JOSM does not keep the selection order.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-07-26 09:33:11 +0200 (Sun, 26 Jul 2020)
Revision:16809
Build-Date:2020-07-27 01:30:49
URL:https://josm.openstreetmap.de/svn/trunk

comment:8 Changed 6 months ago by skyper

Keywords: selection order added

comment:9 Changed 6 months ago by GerdP

JOSM calculates a proper order by calculating rings, doesn't it? Why should it try to keep the selection order which might be completely unordered?

comment:10 in reply to:  9 Changed 6 months ago by skyper

Replying to GerdP:

JOSM calculates a proper order by calculating rings, doesn't it? Why should it try to keep the selection order which might be completely unordered?

You are right, it makes no sense but changing the order of a properly sorted selection does not either, or does it.

Please, only change the order if needed.

comment:11 Changed 6 months ago by GerdP

OK, two different problems here:
1) the way members are indeed "shuffled" in the function that calculdates the rings, this can be changed easily so that the given order is kept.
2) the code finally calls the sort function from the relation editor and this may again change the order even if the order is already OK. Order seems to depend on the direction of the first way.

This code is more complex. I might have a look at this in September unless somebody else fixed it.

comment:12 Changed 6 months ago by GerdP

Order seems to depend on the direction of the first way.

That's wrong. The order depends on the ids of the nodes of the first way of a ring. The current algo looks at the end nodes of the first way and picks the node with the lower id to find the next way in the ring.

So, if the existing relation is ordered in a different way it will be reordered. An alternative algo could use the existing order given by the first two ways to calculate the direction. If they are connected this would give the "wanted" direction in which the following ways should be added to complete the ring, if not any direction would be correct.

Last edited 6 months ago by GerdP (previous) (diff)

comment:13 Changed 6 weeks ago by michael2402

I think we can close this ticket. We changed it so that JOSM orders the multipolygon by rings ~4 years ago, which was more useful than depending on the selection order - so this ticket is obsolete.

comment:14 Changed 6 weeks ago by GerdP

+1

comment:15 Changed 6 weeks ago by michael2402

Resolution: wontfix
Status: newclosed

Current behavior works fine for 'normal' users, since multipolygons normally do not need to follow any special order and we sort the rings quite nicely at the moment.

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.