[PATCH] Another way of computing merged node location

[*Martin*]

Hello

I've implemented third way how to compute location of the merged node. Please see my attached patch.

1. First way is to use location of the last selected node.
2. Second way is to average locations of all selected nodes.
3. Third way is to do weighted average where nearby nodes have lower weight than remote.

This behavior can be controlled by merge-nodes.mode property (0, 1, 2). I would like to create a GUI control in preferences to enable its easy setup, but I am not sure what tab should it belong to.

[*Martin*]

the patch

[bastiK]

You cannot do average on lat/lon coordinates, use EastNorth space or 3D instead.

What is the weighted average supposed to do, exactly?

[*Martin*]

You cannot do average on lat/lon coordinates, use EastNorth space or 3D instead.

Could you please help me with this? For two nodes I am able to find the formula but for more than two I am not successful. In any case results are very good for small distances (eg. 100km and less).

Visual example, (.) represents node:
Classic merge:

Input : ...                       .
Result:        .

Weighted merge:

Input : ...                       .
Result:             .

[bastiK]

Replying to Martin Ždila <m.zdila@…>:

You cannot do average on lat/lon coordinates, use EastNorth space or 3D instead.

Could you please help me with this?

Should be easy: Just use candidates.get(i).getEastNorth(); and new Node(EastNorth en).

In any case results are very good for small distances (eg. 100km and less).

But still, it just looks wrong. :-)

Visual example, (.) represents node:
Classic merge:

Input : ...                       .
Result:        .

Weighted merge:

Input : ...                       .
Result:             .

[*Martin*]

improved patch using NorthEast

[*Martin*]

Attached improved patch. Is it better now? :-)

[*Martin*]

optimized patch

[bastiK]

In [4315/josm]:

applied #6696 - Another way of computing merged node location (patch by Martin Ždila)