Modify

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#7277 closed enhancement (fixed)

Replace geometry of node with way

Reported by: joshdoe Owned by: team
Priority: normal Milestone:
Component: Plugin utilsplugin2 Version:
Keywords: replace geometry Cc: joshdoe, Zverikk

Description (last modified by skyper)

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.

Attachments (1)

utilsplugin2.jar (191.6 KB) - added by joshdoe 9 years ago.
utilsplugin2 with replace geometry supporting node->way

Download all attachments as: .zip

Change History (11)

comment:1 Changed 9 years ago by 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).

Last edited 9 years ago by akks (previous) (diff)

comment:2 in reply to:  1 Changed 9 years ago by 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.

comment:3 Changed 9 years ago by 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.

Last edited 9 years ago by akks (previous) (diff)

comment:4 Changed 9 years ago by akks

Cc: Zverikk added

comment:5 Changed 9 years ago by skyper

Description: modified (diff)

fixed mismatch

comment:6 Changed 9 years ago by 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.

Version 0, edited 9 years ago by joshdoe (next)

Changed 9 years ago by joshdoe

Attachment: utilsplugin2.jar added

utilsplugin2 with replace geometry supporting node->way

comment:7 Changed 9 years ago by 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?

comment:8 in reply to:  7 Changed 9 years ago by joshdoe

Resolution: fixed
Status: newclosed

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?

Last edited 9 years ago by joshdoe (previous) (diff)

comment:9 Changed 9 years ago by 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.

comment:10 in reply to:  9 Changed 9 years ago by 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!

Modify Ticket

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