Replace geometry of node with way

[joshdoe]

Enhance the "Replace geometry" command of utilsplugin2 to allow replacing a node with a way (or multipolygon). Think of this common scenario when you encounter a POI that is a node but you have imagery where you can trace the building outline:

• Draw the building outline as a way
• Merge the existing POI node into one of the nodes of the building outline way (to preserve a connection in the history)
• Copy and paste the tags from the node to the way
• Delete the tags from the node

The last four operations can be easily and logically provided by the "Replace geometry" command.

[akks]

Merging POI into building outline does not sound like a good idea ("extract node" in utilsplugin2 was created exactly to remove such situations). As for me, it is better to leave POI inside the building (by the way, it does not occupy the whole building usually).

[joshdoe]

Replying to akks:

Merging POI into building outline does not sound like a good idea ("extract node" in utilsplugin2 was created exactly to remove such situations). As for me, it is better to leave POI inside the building (by the way, it does not occupy the whole building usually).

I think I might not have been clear enough. Imagine someone puts a node for a stand-alone restaurant in the middle of the building outline. Surely the restaurant information should be on the building, not on the node in the middle of the building.

I think you may have been referring to a building which houses multiple features, in which case I totally agree with you.

[akks]

So, the idea is to incorporate node in new contour without tags. Sorry, I did not understand the first time.
I agree, "Replace geometry" is a right place for this feature.

It is better if this action author Zverikk add the feature himself.

[skyper]

fixed mismatch

[joshdoe]

I've been bold and committed this change in [o27505], but haven't committed a JAR for it yet, as I'd appreciate someone else looking at it (I'll attach a compiled JAR shortly). This should handle any combination of uploaded/new node and way pairs, as it's always considered an upgrade.

Edit: The JAR includes the patch from #7278.

[joshdoe]

utilsplugin2 with replace geometry supporting node->way

[akks]

As for me, I like this version. Only thing I noticed is that node is not included in replacing way, if it is >~100 m away. Maybe we should always include it, because tags are taken from the node before deletion?

[joshdoe]

Replying to akks:

As for me, I like this version. Only thing I noticed is that node is not included in replacing way, if it is >~100 m away. Maybe we should always include it, because tags are taken from the node before deletion?

Done and published in [o27517]. The findNearestNode checks for distance in canvas units with a max hardcoded value of 3e-4. Why this is, I'm not sure, but it seems like it shouldn't have a max value to me. I didn't want to modify the behavior of the classic way->way replacement, so for node->way I just pick the first unimportant node if this check fails. Another ticket for this one, or maybe Zverik can enlighten us?

[Zverikk]

Of course I can. First of all, this feature was developed to quickly fix a lot of buildings. And if a node is too far (and for buildings 150m is far enough) from the original, it can safely be considered not an improvement over the original one, but a completely new one. In this case there's no point in preserving history. This threshold can be made a configuration value, of course, if it bothers anyone.

[joshdoe]

Replying to Zverikk:

Of course I can. First of all, this feature was developed to quickly fix a lot of buildings. And if a node is too far (and for buildings 150m is far enough) from the original, it can safely be considered not an improvement over the original one, but a completely new one. In this case there's no point in preserving history. This threshold can be made a configuration value, of course, if it bothers anyone.

I tend towards trusting the user that they know what they're doing, and if it's not replacing a poorer representation of a feature with a better one that they'll just delete the way instead of replacing it. However, I agree it should be configurable. See #7295 which covers this issue and a few other more important ones. Thanks for all your work on the plugin!