I am separating boundaries from rivers, because they share the same map feature, the same way. What I want is to duplicate the way, by using the same nodes, in order to have the old way for the river properties, and the new way for the boundary properties.
I don’t know how to do that in JOSM. There is a duplicate option (Ctrl+d) but it creates a new way feature with new nodes, so I have to merge the nodes, or move the new way very close to the source feature, and this create crossing issues.
Thank you for the answer, I know this option which is very useful, but for long rivers, divided multiples times is also time-spending. I would like something like Shift-Ctrl+D, hahaha.
I have a function that creates a parallel copy of a way (keyboard shortcut Shift-P), but I am currently unable to find out which plug-in is doing that (and also not sure if that’s what you are looking for).
Ctrl-C + Ctrl-Shift-V (paste at source location), and let the validator fix up duplicate nodes 
Some forum post also suggests: Ctrl+Shift+M (Merge the currently selected objects onto another data layer).
But they create nodes in the same position. It does not reuse them, as when using “Follow line”
That’s why I mentioned the validator to fix the duplicates. - that’s at least the idea… let me double check, if this really works ok consistently.
Hmm. I tried with a single way 180686278 via the single object download, created a copy at the same location as described earlier on. The validator correctly reports 93 duplicate nodes, but the “Fix” button is disabled… bummer.
Back to the drawing board.
So one way would be to save the way in question to a local file, and add a copy of it with a negative way id. For demonstration purposes only, this is how it would look like: dup_way.osm.xml · GitHub
Maybe there’s some good way to achieve the same result on the UI.
Why duplicating the way? If the line is long I would go for two relations that share the same line.
For an example see this way/line, it is used by four relations, in this case all borders but you can do that also for the edge of a river.
I agree, around here a mapper has duplicated all these ways with boundary tags, and it is just much more complicated now to modify the geometries, basically double the work, without any benefit. If you have indications that a specific boundary is placed imprecisely you should improve it, e.g. move it from the center of a road to one of its sides, but if all you want to do is attach a new way at the same position and fuse it with the highway/river/etc., you should probably just not do it, no benefit and more hazzle for everyone. Just reuse the ways in the relations until they actually differ.
Regarding the instructions from Relation:boundary it is not recommended to share the same line.
In fact, there could be a river and another way using the same nodes just for boundaries.
I strongly discourage using physical featuresfor boundaries except when they are officially declared as bounding element by e.g.treaties.
This means the boundary changes when e.g. the waterway changes its way.
Glueing physical and non-physical objects together is nice during creation but it’s a mess for later editing.
Glueing together physical and non-physical objects should be forbidden and not possible to do in any editor!
I’m currently updating roads from a national road database, and where landuses and roads are glued together the work takes at least twice as long.
Good finding but there is more then the green underlined text.
If you map a river and grass land using one way and two relations, you map adhering to One feature, one OSM element:
Sooner or later these features change in reality and get updated in OSM - but usually the shape of the boundary remains.
If so, keep the way as is and only change the relation for example from grass land to meadow.
Yes, do not use this for short sections (you wrote it is a very long river) or if you think it is not appropriate for the situation as relations add complexity.
I think there is a differing interpretation of boundary.
The shoreline is a physical object, bounds or outline would be a less confusing wording. Glueing grassland and river outlines in this example is of course meaningful since changes of one area identically change the other area.
I can imagine one situation where you would need to copy a river to a border, in case the border were defined as following a living river at a specific date. In this case you need to freeze the river into the border, and make sure that nodes are not shared.
I don’t understand the need to share nodes (in different way entities) but not the ways (organizing a relation).
I don’t think it is good idea to duplicate a boundaries between two states or two municipalities, with the duplicate function of JOSM, and to put them close to each other (as I wrongly did in changeset Changeset: 126758302 | OpenStreetMap). It creates empty areas not belonging to any state. The sum of the areas of the states would not be the area of the country that to me sounds a logical validation. Besides with lots in different states that are adjacent, the owners of those lots would not be happy with OSM seeing that the boundaries of their properties loose 1 meter or something according to OSM.
I don’t think it is necessary to duplicate ways using the same nodes of existing ways. And JOSM will emit a warning in those cases.
The examples I see in Germany and France I think are fine, because don’t require useless work of duplicating ways with the same nodes. See for example Way: La Vieille Lauter / Alte Lauter (29412354) | OpenStreetMap it is part of a stream with admin_level=2, border_type=nation and waterway=stream. It belongs to 32 relations including:
Josm will not emit warnings if the nodes belong to ways with different main tag (e.g. waterway vs. boundary).
Nevertheless I would not “glue” the stream nodes to the boundary anyway
On a very fine scale the boundary line is not in the exact middle of the stream but where the surveying defined it. Vice versa the stream will not care about boundaries. If the stream changes its course after a thunderstorm, the nation boundary will not.
As a general rule: Don’t glue physical to virtual objects unless exactly defined by treaties etc.
In the example here the boundary way gets a name which is in normal circumstances considered as an error.
