terracer: deletes addr node without copying any data

[skyper]

terracer deletes addr node without copying any data if the node is already part of the building.

[kachkaev]

Do you mean the case when the addressing node is a part of the way that is the outline of the building?

[skyper]

Replying to kachkaev:

Do you mean the case when the addressing node is a part of the way that is the outline of the building?

Sorry, do not have much time right now. Can test it tomorrow.
Yes, this was the case.

Did not test your updates, but please only move all tags and relation memberships but do not delete or move this node.

Thanks a lot.

P.S.: There were some more tickets concerning terracer (component: Plugin terracer), maybe some were fixed yesterday,too.

[skyper]

Thanks for your work.

I tested with o26029 and the problem still exists. I add a test file.

[skyper]

example file

[skyper]

still no answer on a blocker !!!

[skyper]

typo

[Don-vip]

Can you please explain exactly (step by step) the problem ? I tried to play with terracer and the attached file and found nothing justifying a blocker defect ? (I merged the two building areas in order to terrace the whole result to 14/16/18, and not a single address node has been deleted by the plugin)

[skyper]

Replying to Don-vip:

Can you please explain exactly (step by step) the problem ? I tried to play with terracer and the attached file and found nothing justifying a blocker defect ? (I merged the two building areas in order to terrace the whole result to 14/16/18, and not a single address node has been deleted by the plugin)

Sorry, the description is really terrible:

1. select a building and a addr node
2. terrace
3. the node is deleted and
   • if the node was part of the building no housenumber is added (number 14).
4. In all cases the nodes are removed from the associatedStreet relation and no ways are added which should be default if the nodes were already members.
5. Even after ​​[o29037], if you check create associatedStreet relation, a new relation is created.
6. The order should not be changed (16/18).

May the plugin could use part of the replace geometry command in utilsplugin2.

Please have an option to not remove the nodes which are part of the building as I often use them to mark the entrance. Thanks.

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2012-12-04 02:31:51
Last Changed Author: Don-vip
Revision: 5611
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2012-12-04 00:43:04 +0100 (Tue, 04 Dec 2012)
Last Changed Rev: 5611

Identification: JOSM/1.5 (5611 en)
Memory Usage: 99 MB / 1820 MB (52 MB allocated, but free)
Java version: 1.6.0_24, Sun Microsystems Inc., OpenJDK 64-Bit Server VM
Operating system: Linux
Dataset consistency test: No problems found

Plugin: ColumbusCSV (28043)
Plugin: terracer (29037)
Plugin: utilsplugin2 (28807)

[Don-vip]

ok thanks for the description, I'll try to fix both tickets :)

[skyper]

Replying to skyper:

May the plugin could use part of the replace geometry command in utilsplugin2.

The more I think about it, the closer I get to the conflation plugin which tries to do this in general.

[Don-vip]

In 5612/josm:

see #6178 - Makes DeleteCommand use ChangeNodesCommand instead of ChangeCommand when deleting a node being part of a way.

The previous use of ChangeCommand prevented this use case to work as expected:

• SequenceCommand of:
  • ChangePropertyCommands adding tags to a way
  • DeleteCommand of a node of this way

-> Running the DeleteCommand did cancel the previously run ChangePropertyCommands as the entire way was replaced (including its tags), based on the way state at the creation of the SequenceCommand and not its real current state.

By the way, this could also be more efficient.

[Don-vip]

In 5613/josm:

see #6178 - Change Relation.removeMembersFor(Collection) signature for better flexibility. Impacted plugins: terracer and reltoolbox

[Don-vip]

Can you try version ​[o29047] with JOSM r5613 tomorrow ? Thanks.

[Don-vip]

Replying to skyper:

The order should not be changed (16/18).

one bug at a time :) This one is for #6173 ;)

[skyper]

Replying to Don-vip:

Can you try version ​[o29047] with JOSM r5613 tomorrow ? Thanks.

It is much better. Thanks.

Only problems I found:

• addr:street= is added to every new building way which is not needed if using an associatedStreet or street relation.
• the name= of the relation is used for addr:street= even if the relation also contains an addr:street=. I sometimes have streets with several postcodes, e.g. I have to split the associatedStreet relation in parts with one master relation.
• still no possibility to preserve the node which is part of the building from deletion.

EDIT:

• think if the nodes are already part of the relation, the ways should always be added to the relation despite of the chechbox.