Opened 13 years ago
Last modified 7 years ago
#7468 new defect
Do not delete address nodes but use them as corner node
Reported by: | skyper | Owned by: | Upliner |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Plugin buildings_tools | Version: | |
Keywords: | address node, building_tools_replacement_mode | Cc: | jhfi, brogo |
Description
I already reported this on #7328.
Replying to skyper:
By the way: BT should not delete address nodes but use the node as one corner node with its properties moved to the way.
I agree with you there. As I said, there is room for improvement.
I mark this as defect as you loose the history of the address tags right now.
Attachments (0)
Change History (9)
comment:1 by , 13 years ago
comment:3 by , 9 years ago
Is this an alternative?
Have utils_plugin2 and building_tools plugin installed,
have a single node from OSM database with any addr:xxx data
then draw a building outline via building_tool around this "old" addr: node, but be sure via buildingtools setting that this node is NOT deleted,
Then select that node and also select the new building outline (that consists of four new nodes,
choose via "moore tools" menu the feature of "Replace Geometry" and transfer all tags from the node to the outline,
after that click each of the four nodes of that outline, and see
that one of them is now the OLD one node with the node ID number from OSM database.
Thus we can see that transferring that old node to the building outline is possible!!!!
So we need a transfer from the feature "Replace Geometry" to building_tool, I think.
Is this possible with little effort?
Stephan75
comment:4 by , 9 years ago
First of all there are three possible candidates for the old history:
- The building outline. But as far as I know we have no operations to “merge“ the history of two objects or replace the history of the way with the one of a node.
- Add existing address node to the building outline (as an entrance). But where to add the node (automatically)?
- Replace an existing outline node with old address node, as suggested in this issue.
When I start thinking about the third solution, I found much more arguments against this approach than supporting ones:
- We have to choose an arbitrary victim node to be replaced. This node will loose his history instead. What is the criteria for choosing the node to be deleted?
- Assuming we have a rectangular building, I would never expect the address history at a corner node. Not finding the history is in my opinion the same as loosing the history.
- Assuming some simple terraced buildings. The inner buildings has only nodes which are also part of other buildings. To which building belongs the history, if the replaced node is part of two three or even four buildings?
- If the replaced node is member of more than one way (other buildings, fences, parking places, …), the node must be replaced in all ways. This cause (unnecessary) modifications on all the involved ways.
- Again think about terraced buildings. How do we want to prevent replacing a node which belongs to more than one building more than once? In this case we will loose an old address history anyway.
Edit: This is more suitable for #6285. For this issue (creating a new building), 1.) is not relevent.
comment:5 by , 8 years ago
Keywords: | building_tools_replacement_mode added |
---|
comment:7 by , 7 years ago
Cc: | added |
---|
comment:9 by , 7 years ago
Cc: | added |
---|
The code for this is implemented in Utilsplugin2, in ReplaceGeometryUtils.upgradeNode(Node subject, OsmPrimitive reference). Perhaps it should depend on utilsplugin2, or if building_tools is to be integrated in core, we can consider moving this class from the plugin to core as well.