Modify

Opened 5 weeks ago

Closed 3 weeks ago

Last modified 11 days ago

#19188 closed defect (fixed)

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

Reported by: skyper Owned by: GerdP
Priority: normal Milestone:
Component: Plugin utilsplugin2 Version:
Keywords: template_report circle arc closed way Cc:

Description (last modified by 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)

Attachments (3)

josm_circle_arc.osm (2.0 KB) - added by skyper 5 weeks ago.
sample file
19188-open.osm (1.7 KB) - added by GerdP 4 weeks ago.
select A,B, and C and the way
19188.patch (15.0 KB) - added by GerdP 4 weeks ago.

Download all attachments as: .zip

Change History (24)

Changed 5 weeks ago by skyper

Attachment: josm_circle_arc.osm added

sample file

comment:1 Changed 5 weeks ago by skyper

Description: modified (diff)

comment:2 Changed 5 weeks ago by GerdP

Owner: changed from team to GerdP
Status: newassigned

comment:3 Changed 4 weeks ago by 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?

comment:4 in reply to:  3 Changed 4 weeks ago by 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.

comment:5 Changed 4 weeks ago by 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.

comment:6 Changed 4 weeks ago by GerdP

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

comment:7 Changed 4 weeks ago by 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.

comment:8 in reply to:  7 Changed 4 weeks ago by 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.

comment:9 Changed 4 weeks ago by GerdP

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

Changed 4 weeks ago by GerdP

Attachment: 19188-open.osm added

select A,B, and C and the way

comment:10 Changed 4 weeks ago by GerdP

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

comment:11 Changed 4 weeks ago by 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.

comment:12 in reply to:  11 Changed 4 weeks ago by 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.

comment:13 Changed 4 weeks ago by 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.

comment:14 in reply to:  13 ; Changed 4 weeks ago by 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".

comment:15 in reply to:  14 ; Changed 4 weeks ago by 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.

comment:16 in reply to:  15 Changed 4 weeks ago by 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.

comment:17 Changed 4 weeks ago by 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].

Changed 4 weeks ago by GerdP

Attachment: 19188.patch added

comment:18 Changed 4 weeks ago by 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.

comment:19 Changed 4 weeks ago by GerdP

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

comment:20 Changed 3 weeks ago by GerdP

Resolution: fixed
Status: assignedclosed

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.

comment:21 Changed 11 days ago by skyper

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain GerdP.
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.