Hundreds of duplicate nodes of boundary following stream exactly

We all know these pesky ‘so close nodes, they really have to be connected’. The encounter today is a boundary that follows a stream over a longer distance where the boundary is smack on top, or below if you will of the stream by the hundreds of nodes. The boundary way is actually used in 3 relations.

Solution:

  1. Leave alone/take a rain check,
  2. merge all these overlying nodes, practically re-trace(follow) the boundary line along the stream in a few seconds.
  3. remove boundary line and make the stream a member of the boundary relation, or transfer the stream tags to the boundary section, for ease?

The very high node density I can live with but a simplify would not harm either.

That’s Way: 1254127007 | OpenStreetMap .

An administrative boundary following a waterway is a very common occurrence. I would leave it alone per the advice at Relation:boundary:

However, avoid connecting boundaries to physical features like woods or rivers or reusing their ways as boundaries (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. An exception may be done if the boundary is legally defined to be the physical feature.

And indeed, some waterways are not where they used to be when the boundaries were defined.

5 Likes

It is, and I agree to the advice in the wiki that these ways should not be conncectet to each other, unless the waterway is legally defined as the boundary.

Again the boundaries usually do have much less nodes than the waterways they are following so in a case like this one here I would try to find out if the border really shares each and every node of the waterway.

3 Likes

And indeed, some waterways are not where they used to be when the boundaries were defined.

while this is true, the consequences may vary, it also happens that disputes arise in such situations.

The issue is that “it depends”.

It may be that the middle of the stream is defined as the boundary - thus the boundary changes WITH the change of the stream.

It may be that the boundary is defined as “The stream in 1845” in which case stream and boundary will divert from each other over the decades and centuries.

So the reason by “simplification” or “node reduction” is not what someone wants. It depends on the legal state of the boundary.

Flo

3 Likes

Then again, if this is the case, how remarkable that the stream hadn’t changed one iota since 1845, so that all these nodes just happen to overlap! :open_mouth: I’ve dealt with situations like this where I had to not only detach the boundary from the waterway but also remap it from scratch.

Thats not the point - When its defined as the “middle of the stream at point in time X” the boundary has once been defined and and the once linked object - in this case the stream - may change anytime.

Mappers will then move the nodes to the new center of the stream - that may be just in some small area, and inadvertetly move the boundary with it, which THEN creates an error.

So if the 2 objects are not linked in the correct definition, they should not share nodes.

So by beeing “lazy” or “economical” today - you may produce issues tomorrow.

OSM is about making it simple for the average mapper to keep the entry barrier low. So we need to be disciplined in making objects as simple as possible. This is why i typically rather try to split polygons into small pieces than then to add the 23rd hole in the middle. The simpler the objects, the less error prone they are.

And glueing objects together which may not have any linkage in the real world, and not even legally is just giving us headaches tomorrow.

Flo

2 Likes

By the looks the last change on the stream was 4 years ago V2. (Same mapper did V1) then did boundary refinements 4 months and nothing budged on the stream, still V2. The sat imagery shows denser growth so I think this could have been traced from Lidar or something that is able to look through the canopy or even imported from external source, so speculation on my part, it is likely written up that Fosso di Calinfranco for one is the agreed administrative boundary between several communities.

JOSM has excellent unglue, line replication tools and plugins to achieve any parallel movements, with the measured values pane and status bar info to move the replicant in steps of 50 cm. Use it e.g. measuring the width of a railway cutting, say 8 meters wide, then replicate rail 4 meters to the left and right and cut a corridor through a forest. Picture perfect.

I agree with you. I’m just pointing out that, in the case where they aren’t linked in the real world, it isn’t enough to use iD’s disconnect feature or JOSM’s unglue feature to keep the two features separate. Most likely the boundary is already inaccurate by that point – overconflated – and needs to be redrawn.

And glueing objects together which may not have any linkage in the real world, and not even legally is just giving us headaches tomorrow.

this is true, but objects which are linked in the real world / legally should better be linked in our data as well. There is no single perfect solution, we should strive for the best individual representation