Replace Geometry: keep connections to existing ways

[matf.de@…]

I'm using the Replace Geometry function quite heavily but it would be great if there was an option that would keep the ways that were connected to the original geometry also connected in somewhat the same place to the new geometry

[GerdP]

Thanks for your report, however your ticket is incomplete and therefore not helpful in its current form.

Please add all needed information according to this list:

• The required parts of the Status Report from your JOSM.
  • Please, use Report Bug from Help menu and copy & paste.
• Describe what behaviour you expected.
• Describe what did happen instead.
• Describe if and how the issue is reproducible.
• Add any relevant information like error messages or screenshots.

To ensure that all technical relevant information is contained, create new tickets by clicking in JOSMs Main Menu on Help → Report Bug.

Remember: This is a generic notice so we don't need to write the same stuff again and again. It may only apply in parts to the specific case!

Please attach data that shows what you get and what you would like to get instead.

[matf.de@…]

Hi this is not really a bug but rather a feature request.
I have recorded the following video to demonstrate the feature request: ​https://drive.google.com/file/d/1PFYVX5j12Mk2SGAlSkd4nTXFmP-8PI0c/view?usp=sharing

As you can see I am replacing the geometry of a way. After the "replace geometry" action I have to attach the new way to the stubs where the old segment was connected as well as create a connection with the crossing way in the middle.

Now I think that it would be incredibly useful if there was a mode or a setting for "replace geometry" which would automatically attach all the connections that were made with the nodes in the old way also with the new way.

I believe that the beginning and the end of the way could be relatively easy attached to anything that was attached to the old way as well. It would be trickier with anything that's attached to the middle of the old way.

I hope that makes it clearer :)

[GerdP]

I wonder why you draw the new way like that. I would draw it so that the nodes are already connected before using replace.

[matf.de@…]

Good point. For added context.
In Sweden, we have an import project (or rather a coordinated mapping effort) going on where a script converts the official road database of Sweden into an OSM file. Then the mappers load that OSM file into JSOM and can use the replace geometry feature to merge the new imported geometry and the tags that make sense with what's already there to not loose the context of the way that was already there.
See here: ​https://wiki.openstreetmap.org/wiki/Import/Catalogue/Sweden_highway_import

That's why for this usecase, the ways are not actually drawn.

[GerdP]

Can you please attach a real world sample *.osm file containing some existing OSM data and one or more of the imported ways? I still don't understand how replace geometry could be used here.
Attach a second file that contains the wanted result.

[matf.de@…]

Sure.
Take this file for example and load it into your JOSM: ​https://nvdb-osm-map-data.s3.amazonaws.com/osm/nynashamns-kommun.osm
This is a sample output of the script that generates osm files from the Swedish Highway database.

Now the challenge is to merge this with the already existing data in OSM without being destructive. Sometimes the highways align perfecty and there is nothing to do apart from maybe moving some tags over. Sometimes a highway is missing in OSM and then it can be copied over and manually connected.
But most of the time, the way is already in OSM but maybe with a rougher geometry and then the easiest way to merge the data is to use "replace geometry"

[GerdP]

I think it's not possible to automate that part. See e.g. way 437087795. It is connected to a path at node 4349198549 but the replacement way is not.
I don't see how JOSM could decide which node of the replacement way should be used for the connection. So, your part of the work is to find the connections and to merge the existing nodes with the replacement way before using replace.

[anonymous]

I guess it could pick the closest node that's available? I would not expect it to produce perfect result but rather to produce something that can then be improved manually with less effort than to connect all the ways by hand again.

[skyper]

For imports like this, I think the conflation plugin should be used. I just tried it with default settings and "Advanced" matching method. Selecting both, the way and the node, matching works perfectly, but conflation does not work for the node with a message: Cannot replace geometry Node belongs to way(s), cannot replace.

On the other hand, I face similar problems with manually drawn ways when updating building blocks in cities where some or all buildings are connected to each other or even with a single building with some building:parts.

• all nodes with multiple parent ways are problems
• any entrance node is a problem

I usually solve this by merging all nodes with tags or with multiple parent ways in advance, one after the other, but this is little bit annoying and in case of replace geometry, in solo, error prone. (I usually mess up with some and find deleted nodes in the upload dialog)

The major reason for denying these replacement is that the subject node should be inside download area and the possibility of several tags/membership conflicts. Atm, replace geometry works without any download area. I just tried the example by downloading only the two involved ways, merging the connection node manually and then use replace geometry and it worked but I think, I just found a dangerously workaround if the user is used to work without download area or working with some layers and merging (objects) back and for.

Conclusion:

• replace geometry should not work without any download area -> new ticket.
• replace geometry should use nodes with tags, too, inside a download area, as expert mode option
• replace geometry needs to support replacement of nodes with multiple parent way inside a download area, as expert mode option.
• conflation plugin should still have an option to replace without any download area, preserving the dangerous behavior of replace geometry as users of this plugin should know what they do.
• conflaction plugin needs to support replacement of nodes with multiple parent way as option.

Just my 1$

[skyper]

Replying to skyper:

• replace geometry needs to support replacement of nodes with multiple parent way inside a download area, as expert mode option.

Actually, I played around and I do not know if the current behavior is the best solution. Thinking about ways which need to be connected like highway, waterway or boundary, atm, all connecting ways are not connected after the replacement, anymore.

Therefore it might be much better to keep the shared node with its id when replacing than using a new node without connection. The simple solution would be to deny replacements when the subject way has shared nodes which are not part of the reference way.

[matf.de@…]

Yes exactly that is the problem.
I would not deny the replacement because that would break usecases like the one I described.
But I think it might be great to have an option to keep the shared nodes and also keep them connected

[skyper]

See also #10992 and #20966.

[nkamapper]

I think it is best to keep these nodes detached. In most cases they belong to for example parking lots or farmlands which have previously been attached to a highway, but which should rather be kept as separate ways. Separated ways are easier to move around before reattaching them. I prefer to control which nodes should be reattached after the replacement. And it is quicker to merge nodes than to unglue them.

[skyper]

Ok, there are option needed as it depends on several aspects. Areas might need different treatment than linear objects and the tagging style plus the depth of mapped details can be a factor.

Replying to nkamapper:

And it is quicker to merge nodes than to unglue them.

I doubt that but maybe with conflation plugin. With core actions I know Unglue Way and Disconnect Node work with multiple shared nodes but merge only for one shared node.
In the situation you describe above, though, I agree that it is much easier to delete or merge after replacement.