circle arc: Issues with three selected nodes and a selected closed way

[skyper]

Follow up of #18847.

Bit late, but I found still some issues with "circle arc" and three child nodes plus their parents, a closed way selected, Please, use attached sample file (josm_circle_arc.osm​).

What steps will reproduce the problem?

1. Select either nodes A-C, F-H or X-Z and the closed way
2. "Circle arc"

What is the expected result?

New nodes will be children of the way

What happens instead?

Unconnected nodes are created

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

One problem seems to be if the end/start node of the way is involved.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-05-01 13:13:43 +0200 (Fri, 01 May 2020)
Revision:16390
Build-Date:2020-05-02 01:30:45
URL:https://josm.openstreetmap.de/svn/trunk

Plugins:
+ utilsplugin2 (35248)

[skyper]

sample file

[GerdP]

Yes, it matters where a way starts and and ends, but it doesn't matter if the way is closed or not.
When the way is selected the nodes are considered in the order in which they appear in the way, in this case the order is C,A,B
Do you have an idea how the action could detect that a different result might be wanted?

[skyper]

Replying to GerdP:

Yes, it matters where a way starts and and ends, but it doesn't matter if the way is closed or not.
When the way is selected the nodes are considered in the order in which they appear in the way, in this case the order is C,A,B
Do you have an idea how the action could detect that a different result might be wanted?

I found out that there is a major differences between only three nodes and a way and three nodes. For the first the order of selection matters for the later it should not.

In the case of a closed way, the smallest way distance between the selected nodes and could help to find the correct order, than use the smaller angle.

By the way, I noticed that unselected nodes with tags or membership are not treated special, similar to nodes with more parent ways, see #19195.

[skyper]

I see, the problems are not selected nodes in between.

• For unclosed ways the order in the way's nodes list can be use to determine the correct order
• For closed ways the smallest distance of way length should give the right order. E.g.

1. Calculate the all three way lengths between the three nodes.
2. Choose the node with the smallest sum of lengths as middle node.

If nothing works, better demand a order in selection than producing unpredictable results by guessing the order.

[GerdP]

See also #7341. Maybe with closed ways we must use the order in which the nodes where selected.
Nice brain teaser ;)

[GerdP]

Your example shows there is a general problem in the calculation of the nodes to add. Use the same example
1) Select node between G and H and node between H and X
2) split way and remove the Way containing H
3) Select the node between A and B and the nodes C and F and the way
4) Press Shift+C to create arc
Result is garbage. I first thought that the changes for #19195 could be the reason but they are not.

[skyper]

Replying to GerdP:

Your example shows there is a general problem in the calculation of the nodes to add. Use the same example
1) Select node between G and H and node between H and X
2) split way and remove the Way containing H
3) Select the node between A and B and the nodes C and F and the way
4) Press Shift+C to create arc
Result is garbage.

No, only the last step is missing: Merging/Padding the way into the calculated arc.

[GerdP]

Oh, I've added a bad patch instead of a simplified sample. I hope I found a solution, will continue tomorrow.

[GerdP]

select A,B, and C and the way

[GerdP]

I've attached the simplified sample. On my machine the result is an extra full circle (with plugin version 35435)

[GerdP]

I have a solution for most of the problems, but I really wonder what to do with tagged or connected nodes when the calculated position is not on the arc or when multiple nodes fall onto the same place.

[skyper]

Replying to GerdP:

I have a solution for most of the problems,

Nice.

but I really wonder what to do with tagged or connected nodes when the calculated position is not on the arc or when multiple nodes fall onto the same place.

Did not test with multiple ways sharing all nodes, yet. These ways might need a special handling when counting nodes' parents and when adding ways and changing the nodes' order in the ways.

Please, do not delete nodes with positive id. Merging untagged and only connected to the way(s) nodes with id:0 onto other nodes is ok, as merging nodes with id:0 onto untagged and only connected to the way(s) other nodes.
If there is need, think about using more nodes for the arc than the calculated minimum.

[GerdP]

I've probably not made clear what happens. As long as you select nodes which already form almost a circle everything is fine.
Problems start when the moved nodes form loops when we keep the original order. My current approach is sort the nodes first by angle to center of circle. With your example and A,G,H and way selected F is moved after G.
No idea if that makes sense. The action might just show a notification that the selection cannot be used.

[skyper]

Replying to GerdP:

I've probably not made clear what happens. As long as you select nodes which already form almost a circle everything is fine.
Problems start when the moved nodes form loops when we keep the original order. My current approach is sort the nodes first by angle to center of circle. With your example and A,G,H and way selected F is moved after G.
No idea if that makes sense. The action might just show a notification that the selection cannot be used.

+1
You can still work with helper lines and "replace geometry".

[GerdP]

+1 for "makes sense" or "just show a notification"?

You can still work with helper lines and "replace geometry".

Yes, thought about this as well, but that action also fails sometimes.

[skyper]

Replying to GerdP:

+1 for "makes sense" or "just show a notification"?

just a notification.

You can still work with helper lines and "replace geometry".

Yes, thought about this as well, but that action also fails sometimes.

Meant this as manual steps and you have to take care of tagged nodes and way connections yourself.

[GerdP]

Did not test with multiple ways sharing all nodes, yet. These ways might need a special handling when counting nodes' parents and when adding ways and changing the nodes' order in the ways.

In fact the current code adds new nodes only to the selected way. I'll have a look again at the version before [o35384].

[GerdP]

I think the patch fixes all problems we discussed so far. In some cases it will show notifications like
Could not use selection to create a curve: Too many fixed nodes
Could not use selection to create a curve: Don't know which part of closed way should be changed

One minor issue remains: When new nodes are added to an existing way the algo doesn't try to find the best position. In some cases original nodes are moved further than needed. Will work on this tomorrow.

[GerdP]

The texts are not yet good, should not use single quotes and the phrase "fixed nodes" isn't self explaining.

[GerdP]

See [o35440:35441]

• I decided to ignore "fixed" nodes when they produce problems.
• Closed ways might produce a notification "Could not use selection to create a curve: Could not detect which part of the closed way should be changed"

I hope I found all special cases now. In general, arcs in the west are more problematic because the angle switches from -pi to pi.
I am not 100% happy with the calculation of the "fixed" nodes. When you have two ways sharing one or more segments those shared nodes are not really special, but they are treated as such because it is complex to distinguish them from ways connected otherwise. Result is that more new nodes are added where existing nodes could be moved.

[skyper]

Did not test it extensively, but for my common use cases this works like a charm, now. Thanks a lot.