Talk:Duplicate nodes map

Sorry, but this is pretty useless

It needs to omit dupes of roads and non-roads (except for roads and railways) - see http://matt.dev.openstreetmap.org/dupe_nodes/?zoom=16&lat=36.85727&lon=-82.76092&layers=BT for one of many examples of a road along a jurisdictional boundary, which should not be joined. This also applies to power lines and pipelines. --NE2 21:51, 26 February 2010 (UTC)

There doesn’t seem to be any trouble in South Dakota. --Andrew 11:30, 27 February 2010 (UTC)

Because someone connected the roads to the boundaries. --NE2 19:50, 27 February 2010 (UTC)

Fixes done wrong aside, imo where a road is the border (or the other way round), the ways should use the same nodes. But there seems to be varying opinions, even among those who've discussed this on the talk list and on #osm. Power lines don't have a tower/pole on any road, so they're worth fixing - not just merging - too. Pipelines might have a manhole in the middle of the street and the ways might well "be connected" - or the other node moved to a better location. Alv 17:46, 4 March 2010 (UTC)

The most recent (?) discussion on the talk list agrees that they should not be connected. --NE2 18:15, 4 March 2010 (UTC)

Power lines in the imported TIGER data are joined correctly in a topographical routing sense. They are not joined to the roads, BUT for some reason they are always represented with a pair of nodes sat on top of each other (duplicate nodes!) This doesn't present a routing problem.

The correct fix for this kind of duplicate node is NOT to merge the pair of nodes. Then you are potentially creating routing problem (although it's a pretty odd router that sends you down a power line!) Essentially you'd be making the data inaccurate. There's no join between the power line and road, and no specific feature at that point.

The correct fix in this case is to shift the power line node off to one side of the road. The reason for this is purely to eliminate the duplicate node, and help make the data easier to work with. Often you'll want to keep path the power line in exactly the same place where it was (unless you can somehow improve it's positioning based on seeing linear tree clearings in the imagery) The position of the node for a power line is fairly arbitrary, simply serving to represent the path of that power line, unless the node is also representing a pylon (tagged power=tower) You may decide to delete the node from the power line or from the road, or both, in cases where there are more nodes than necessary to represent the way.

Boundaries in the imported TIGER data are often sat on top of whole lengths of road, with every node a duplicate of one underneath, and the way itself also a duplicate. If you just merge all the nodes, then you end up with a duplicate way (a way connected all the same nodes as another way) This is a less serious problem, so I guess you're making progress. Alternatively I think the JOSM validate plugin has a case to deal with it, and fix it nicely so that a single way has both the road and boundary tags.

-- Harry Wood 15:11, 5 March 2010 (UTC)

But is the boundary the centerline of the road, or off to one side? (Depends, but unless it's an old boundary it will probably be to one side to simplify maintenance issues.) If the road is realigned to smoothen curves, does the boundary follow? (No.) Does joining the road to the boundary offer any benefit? (No; it makes future editing more complicated if anything.) More common is where a road crosses a boundary. At a county line, the two roads will each end with their own nodes at the boundary, with a third 'duplicate' node on the boundary way. Here only the roads should be joined. --NE2 18:07, 5 March 2010 (UTC)

Hmmm. Ask me those questions I'd be tending to answer differently. "If the road is realigned to smoothen curves, does the boundary follow? (Yes.) Does joining the road to the boundary offer any benefit? (Yes)

I imagine in many cases the most precise definition any government agency has for where the boundary lies will be "along this road". In some cases we may know better, in which case put the boundary exactly where we know the boundary is. Either it's attached to the centreline of the road, or it's off to one side of the road. For sections of boundary along a road, any adjustments in accuracy of our road definition, may as well be applied to the boundary too, and that happens automatically if you have two ways sharing nodes. One might argue that it would be nicer to represent this as a single way with both highway and boundary tags. One thing which I would argue is not a nice way of representing it... is with duplicate nodes as well as duplicate ways, because that really is confusing data mess. But you seem to be disagreeing with me on that. -- Harry Wood 12:37, 27 March 2010 (UTC)

In my experience, boundaries do not move with manmade features; they don't even move with natural features. For instance, Carter Lake, Iowa is on the Nebraska side of the Mississippi River because the state line follows the old channel. Moving the border requires an actual decision, such as the resolution of the Chamizal dispute. --NE2 00:41, 28 March 2010 (UTC)

Interestingly, those links indicate that gradual changes in natural features (rivers changing course over time, specifically) also move the boundaries linked to those features; it's only abrupt changes, like the 1877 Missouri River flood, that leave boundaries unchanged. --Asciiphil 15:57, 31 March 2010 (UTC)

Road realignments are always abrupt :) (unless it's a de facto path that shifts slowly over the years) --NE2 01:58, 1 April 2010 (UTC)

Ah ok. Rewind. You're talking about real life realignments to smooth curves. Actual rebuilding of the road in a new position.

We regularly adjust or re-align roads in the OpenStreetMap data, to fix up inaccurate TIGER data, or to add more accuracy to it, i.e. better representing where the road is in real life. That's what I thought you meant. At the moment this is probably more common and more of a concern than the cases where road works in the real world change the positions of boundary roads.

Hence data on top of data (with dupe nodes) is not the most helpful way to have it represented.

-- Harry Wood 12:44, 15 July 2010 (UTC)

I think it's most useful for the map data to reflect the underlying legal definition of the boundary, when that's known. It's common for a border to actually be defined by a river or shoreline, and sometimes to be defined by a road (AIUI, typically the border goes down the road's centerline, with the road's right-of-way extending into both regions). Ideally, IMHO, the river would simply be a member of the relation(s) that represents the border(s). In the case of avulsion (vs more gradual change) we would need to remap the river anyway, and can leave nodes representing the old waterway and unmoved border in place. On the other hand, if a border and another feature just happen to coincide, then I don't think they should share ways or nodes. -- WimL 22:02, 25 August 2012 (BST)

French survey point have been imported in OSM and about 14.000 duplicate points appeared with it. Indeed, they are not. Usually, a geodetic site consist in several geodetic points. A classical case is two different points on the top of the church. Have a look at [1]. They can't be merged together because first they are not identical and second there are tags in conflict (description, ele, ref and url). Overall I think that not counting as duplicate points with tag in conflict would be a good criteria. --Eric S 20:36, 30 March 2010 (UTC)

from Ceyockey: Personally, I find this a useful resource. Yes, it does throw up false positives, but when you do mass imports or several people are trying to import things in the same area (ala some HOT activities), this can help to resolve duplication (avoidable or not) in a reasonable time after the import frenzy has subsided. --00:13, 23 December 2010 (UTC)

Section removed

I removed an insulting section. There are ways of sending message to people in OSM. There is no need to point out people and give them bad names. It is better to explain them waht's wrong. Nakor 16:01, 14 May 2010 (UTC)

Why not two nodes at the same location?

There are some exceptions where two nodes at the same location make sense: e.g.: a public phone with a mail box attached. This is quite common in Germany. Putting both in one node is not possible and creating two nodes with a distance of 1 meter is not possible with JOSM (minimum distance 0.0001 degress = aprox. 10 meters). Because we collect geographic data I think it is a leagal approach to put them both in one location.

N.B.: I found this tool, because a mapper used this tool and deleted all my points of interest I mapped 8-(, e.g. public telephones, mail boxes, recycling containers, ..., which I mapped in a single node. Need now to figure out, how this can be reversed.

User:Flomigulau - 19:21, 11 October 2010

Post on the talk mailing list, and if that doesn't work kick his ass. --NE2 21:36, 11 October 2010 (BST)

Huh, 10 meters? I regularly add nodes much closer to each other than that. The only limit might be at the "enter coordinates for a new node" dialog; when one clicks the canvas in draw mode you get to add nodes easily within centimeters of each other. There was, if I remember correctly, in the past a version of josm that did truncate coordinates excessively, but even that allowed six digits. Alv 22:21, 11 October 2010 (BST)

Yeah I don't know where this 10 meters idea comes from. JOSM actually makes it quite difficult to land two nodes on top of eachother! How are you even doing that? The objects are next to eachother in the real world. Place the nodes next to eachother. -- Harry Wood 02:15, 12 October 2010 (BST)

It's certainly plausible for two items to be directly on top of each other: a phone and a side-loading trash can, for example. --NE2 13:23, 12 October 2010 (BST)

"A phone and a side-loading trash can"? So they're directly above/below eachother? if you take the centroid of the area occupied by the phone, and the centroid of the area occupied by the trash can (as viewed from above), then these fall on the exact same (to the millimetre) location? Is that what you're saying? That could be a legitimate use of duplicate nodes. If however the trash can sticks out by a couple of millimetres under the phone, or if, I don't know, you just for some crazy reason wanted to make your data more useful and useable, you could position the nodes not directly on top of eachother.

Anyway that doesn't seem to be what User:Flomigulau is talking about with his strange "approx 10 meters" comment. He seems to be mapping things which are near eachother, and seems to be confused. I'm not advocating deleting his contributions mind you. Shame somebody did that.

-- Harry Wood 16:17, 7 July 2011 (BST)

Server that this is running on?

from Ceyockey: I'm curious -- is this running on an account on errol? The reason why I ask is that it seems to not be serving dup data and eroll is presently down. Perhaps a coincidence, but I thought I would ask. --00:18, 23 December 2010 (UTC)