Create Multipolygon (Ctrl-B) shuffles the ways

[karljunk]

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.

[naoliv]

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

[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.

[simon04]

In 6807/josm:

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

[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?

[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.

[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

[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?

[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.

[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.

[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 order would be correct.

[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.

[GerdP]

+1

[michael2402]

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.