Circle arc: Nodes with multiple parents should still be distributed if they appear in same/reverse order in the ways' node lists

[skyper]

I reported this in #19979, see my comment 8. Please, use josm_19979_example_v2.osm​.

What steps will reproduce the problem?

1. Remove name=+ from the four nodes
2. Select the open way on the right side and nodes C, D and Y.
3. Circle arc
4. Circle arc

What is the expected result?

The nodes should be evenly distributed along the circle and only the nodes with tags should be moved minimal.

What happens instead?

• after 3. nothing
• after 4. message; nothing to do

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

It should be save to distribute all nodes on their "halves" and in my case, as all nodes are new, even the order could be changed to proper distribute along the whole arc.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-10-22 00:52:01 +0200 (Thu, 22 Oct 2020)
Revision:17249
Build-Date:2020-10-22 01:30:48
URL:https://josm.openstreetmap.de/svn/trunk

Plugins:
+ utilsplugin2 (35608)

[GerdP]

Just to make sure: You expect the same result that you get for these steps when the closed way is removed?

[skyper]

Replying to GerdP:

Just to make sure: You expect the same result that you get for these steps when the closed way is removed?

To keep it simple, yes.

The special case with (only) new nodes is not covered in "normal situations" with only one single way, atm. Probably a new ticket.

[GerdP]

The following small patch achives the result as mentioned in comment:2, so it distributes more nodes, but nodes are only distributed between fixed nodes. Distributing them evenly would require a different algo, and I don't see why it should be done.
BTW: My favorite alternative to this moving would be removing, as those new and untagged nodes are not useful, but that again would require more work.

src/org/openstreetmap/josm/plugins/utilsplugin2/curves/CircleArcMaker.java

@@ -165 +165 @@
         if (!selectedWays.isEmpty()) {
             for (int i = pos1 + 1; i < pos3; i++) {
                 Node n = nodes.get(i);
-                if (n.isTagged() || n.isReferredByWays(2) || n.referrers(Relation.class).count() > 0) {
+                if (n.isTagged() || (!n.isNew() && n.isReferredByWays(2)) || n.referrers(Relation.class).count() > 0) {
                     fixNodes.add(n);
                 }
             }

[skyper]

Is it really that simple? My example has only new nodes but how about existing nodes with id>0? I first noticed the problem with buildings and their building:part. I tried to smoother the arc but failed.

[GerdP]

OK, now I understand what you are trying to do. I already wondered in what mapping situation you find that problem. The patch would not help here.

[skyper]

I face this situation with areas sharing segments, both, from the inside or from the outside. The areas can be closed ways or open ways (multipolygon). Additional, open ways, like line barriers, sharing segments with areas is another case.

Anyway, the patch is an intermediate step, as I could work around the issue with new objects. It is a pity that #9929 prevents me from having a nice workflow with new objects this way.

[GerdP]

Not sure if you are happy with the small patch. If not, please attach an example that shows why it is not enough.

[skyper]

Replying to GerdP:

Not sure if you are happy with the small patch. If not, please attach an example that shows why it is not enough.

Sorry, I am not completely satisfied with it. Thought a small example will work but was wrong. Gonna attach a complex example, later.

[skyper]

One example is ​w194516181 where I had problem but I`ll gonna find more complex examples.

[GerdP]

I guess I understand what you want but this is really a special case and I see no simple implementation yet. What I have in mind is at least 50 lines of code with the corresponding risk to add new problems.

[skyper]

Replying to GerdP:

I guess I understand what you want but this is really a special case and I see no simple implementation yet. What I have in mind is at least 50 lines of code with the corresponding risk to add new problems.

Ok, how about adding the small patch for new nodes for now, and I see, if I can find a simple workaround. Compared to my problems with "Replace Geometry" and nodes with more than one parent way, I face this problem only occasionally.

[GerdP]

In 35624/osm:

see #19985: Circle arc: Nodes with multiple parents should still be distributed if they appear in same/reverse order in the ways' node lists

• don't fix nodes with multiple parent ways when node is new

Not a solution _{but a step forward}

[GerdP]

In 35625/osm:

see #19985: Circle arc: Nodes with multiple parents should still be distributed if they appear in same/reverse order in the ways' node lists
dist