Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

Duplicate nodes on certain types of ways could be handled better #2708

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 22 comments
Closed

Comments

@openstreetmap-trac
Copy link

Reporter: NE2
[Submitted to the original trac issue database at 4.16pm, Wednesday, 10th February 2010]

Because of the TIGER import, there are a lot of duplicate nodes in the US where roads intersect railways, power lines, pipelines, and administrative boundaries. The former should definitely be fixed, but power lines, (maybe) pipelines, and boundaries should probably not be joined to roads.
Boundaries cause a more serious problem when you have two roads intersecting at a boundary (example: http://www.openstreetmap.org/browse/node/67031855). It now looks like the two roads are not joined to each other, when in fact they are; they're just not joined to the boundary. This also affects http://wiki.openstreetmap.org/wiki/TIGER_fixup/County_borders since every such county border crossing will look unconnected unless joined to the border.

@openstreetmap-trac
Copy link
Author

Author: Richard
[Added to the original trac issue at 9.14pm, Thursday, 11th February 2010]

I wouldn't be averse to adding that (though it won't be simple), but you need to get agreement from the various mailing lists - principally talk@ and talk-us@ - on what tags count as dupes and what tags don't. I can't really do it on one person's say-so and I don't have the time to follow the inordinate tagging discussions in depth, I'm afraid. Let me know how you get on!

@openstreetmap-trac
Copy link
Author

Author: NE2
[Added to the original trac issue at 10.12pm, Thursday, 11th February 2010]

How about at least making it show up at a circled square if there's some connectivity? Right now it's impossible to tell if two ways are connected across a county line without dragging the node.

@openstreetmap-trac
Copy link
Author

Author: NE2
[Added to the original trac issue at 10.12pm, Thursday, 11th February 2010]

(by circled square I mean circle the larger square connected node symbol)

@openstreetmap-trac
Copy link
Author

Author: Richard
[Added to the original trac issue at 10.26pm, Thursday, 11th February 2010]

If I get a chance. It's not impossible, incidentally, you can use the Inspector.

@openstreetmap-trac
Copy link
Author

Author: NE2
[Added to the original trac issue at 12.15am, Sunday, 14th February 2010]

Email sent to talk list; waiting for the moderator to accept it.

@openstreetmap-trac
Copy link
Author

Author: Richard
[Added to the original trac issue at 2.02pm, Sunday, 14th February 2010]

Great stuff. You may need to sign up for the mailing list and resend (don't worry, you can choose to disable mail delivery); unfortunately, because the mailing list admin addresses attract ridiculous quantities of spam, it's quite common for regular moderator requests to go unread. If you're subscribed to the list then your message will go through without needing to be checked by the moderator.

@openstreetmap-trac
Copy link
Author

Author: NE2
[Added to the original trac issue at 1.51pm, Monday, 15th February 2010]

There doesn't seem to be any disagreement: http://lists.openstreetmap.org/pipermail/talk/2010-February/thread.html#48118

@openstreetmap-trac
Copy link
Author

Author: NE2
[Added to the original trac issue at 2.06pm, Monday, 15th February 2010]

Related forum thread: http://forum.openstreetmap.org/viewtopic.php?id=6407

@openstreetmap-trac
Copy link
Author

Author: Wynndale
[Added to the original trac issue at 11.12am, Saturday, 20th February 2010]

An alternative approach would be to highlight nodes connected to only one way instead. Apart from not highlighting intersections with other features unless the road is broken there, this also shows a problem sometimes found where roads are not connected and there is no node on the road they should intersect.

@openstreetmap-trac
Copy link
Author

Author: NE2
[Added to the original trac issue at 6.46pm, Saturday, 20th February 2010]

That wouldn't help for cases like http://www.openstreetmap.org/edit?lat=36.85998&lon=-82.75545&zoom=17&way=15513691 where there's one road and a boundary. Related, when you have a lot of closely spaced duplicates, it's like a game trying to select the correct one (without zooming in) - this affects normal editing as much as joining.

I've become convinced that this "feature" does more harm than good. How do I turn it off?

@openstreetmap-trac
Copy link
Author

Author: SK53
[Added to the original trac issue at 6.59pm, Tuesday, 23rd February 2010]

The new flashing nodes feature certainly substantially helps in identifying and fixing duplicate nodes. As it only applies when a given way is selected it does not in my experience affect normal editing. However, I have noticed one aspect of these extensions which could be altered to avoid errors and reduce key-strokes.

Typical deduping edits on TIGER and NHD data often involve joining the ends of ways (e.g., at county lines, or stream/river/lake intersections). The current default behaviour after completing such edits (after pressing "J") is that the mode is to extend the current selected way, which a) can lead to erroneous edits; and b) involves a second key press to ensure one remains in a node edit mode (i.e., no way extension). My experience is that a typical edit sequence will be to move from dup-node to dup-node, and that way edits are unusual in this scenario.

I therefore request that, if possible, immediately after a join-nodes action, that the state remains in 'node-edit' rather than 'way-edit'. I think this is equivalent to doing "J" followed by "RETURN". Obviously the behaviour of SHIFT-J may need to be considered as well.

@openstreetmap-trac
Copy link
Author

Author: gadget
[Added to the original trac issue at 9.13pm, Tuesday, 23rd February 2010]

I'm not sure if Lat Lon are stored on the back end for nodes. If so, for any duplicate node that is part of an Administrative Way do the following:

Shift the Lat or Lon by the following amount depending on the resolution of the data that is stored. It should be within the margin of error for many GPSs units out there. Even the 1 m offset wont vary much from the skew that is created from leaving a GPS logging from a single point for a few hours.

Decimal Degrees between points == Distance the points are apart along the equator(worst case as longest distance)

0.00000001 == 1.1119927 mm
0.0000001 == 1.1119927 cm
0.000001 == 11.119927 cm
0.00001 == 111.19927 cm
0.0001 == 1.1119927 m

The Online TIGER map claims they have 7 decimal digits of accuracy, but I can't image how they would go about verifying it, laser maybe?

@openstreetmap-trac
Copy link
Author

Author: NE2
[Added to the original trac issue at 3.11am, Wednesday, 24th February 2010]

SK53, try doing "normal editing" by selecting a specific node on http://www.openstreetmap.org/edit?lat=36.85998&lon=-82.75545&zoom=17&way=15513691 (in order to split, for instance).

@openstreetmap-trac
Copy link
Author

Author: Richard
[Added to the original trac issue at 10.49pm, Sunday, 7th March 2010]

NE2 - thanks for the mailing list thread. Could you please summarise (for the benefit of someone who doesn't follow tagging discussions) what the behaviour should be.

Something like:

If node is in (way 1) highway=* and (way 2) highway=*, it's a dupe.

If node is in (way 1) highway=* and (way 2) boundary=*, that doesn't make it a dupe.

And so on. Thanks.

@openstreetmap-trac
Copy link
Author

Author: Richard
[Added to the original trac issue at 10.50pm, Sunday, 7th March 2010]

(Sorry, I should have said: "summarise with explicit reference to the tags in question, so I don't have to wade through 982347556 badly-written wiki pages trying to document tagging" :) )

@openstreetmap-trac
Copy link
Author

Author: NE2
[Added to the original trac issue at 6.03am, Monday, 8th March 2010]

I believe all the types of way that might have this problem are:
highway=
railway=
power=
*man_made=pipeline
boundary=

Now assume two nodes A and B are in the same place. If A and B both have parents of the same type, they're dupes. Otherwise they're not, UNLESS one has a highway parent and the other has a railway parent, and those are on the same layer (layer=, with bridge=yes implying layer=1 and tunnel= implying layer=-1).

This is my understanding, at least. Others, feel free to rip me a new one :)

@openstreetmap-trac
Copy link
Author

Author: NE2
[Added to the original trac issue at 11.40pm, Tuesday, 23rd March 2010]

Even worse - much of the time you can't undo improper joinings, since when you try to save it gives you a precondition failure, for example:

Precondition failed: Way 37916806 requires the nodes with id in (-78,-77,-76,-75,-74,-73,-71,-70,-69,-68,-67,-66,-65,-64,-63,-62,-61,-60,-57,-56,-55,-54,-53,-52,-51,-50,-49,-48,-47,-46,-45,-44,-43,-42,-41,-40,-39,-38,-37,-36,-35,-34,-33,-32,-31,-30,-29,-28,-27,-26,-25,-24,-23,-22,-21,-20,-19,-18,-17,-16,-15,-14,-13,-12,-11,-10,-7,-6,-5,-4,-3), which either do not exist, or are not visible.

@openstreetmap-trac
Copy link
Author

Author: NE2
[Added to the original trac issue at 9.23am, Thursday, 1st July 2010]

It's been essentially decided on talk-us that boundaries should not be glued to roads: http://lists.openstreetmap.org/pipermail/talk-us/2010-June/003450.html and replies (or lack of opposition)

Therefore I'm changing this from "major enhancement" to "critical defect" since the present method encourages bad mapping in at least one large country.

@openstreetmap-trac
Copy link
Author

Author: Richard
[Added to the original trac issue at 9.27am, Thursday, 1st July 2010]

At present (and for at least the next couple of weeks) I'm not doing any work on Potlatch 1; Potlatch 2 is the current focus of work. You or any one else are of course very welcome to change it yourself, but I'm afraid that right now elevating the priority won't make any difference.

@openstreetmap-trac
Copy link
Author

Author: NE2
[Added to the original trac issue at 1.22pm, Thursday, 1st July 2010]

It might help you make sure it's fixed in Potlatch 2 :)

@openstreetmap-trac
Copy link
Author

Author: Richard
[Added to the original trac issue at 1.45pm, Thursday, 1st July 2010]

Heheh. Actually P2 doesn't have any form of dupe node handling yet (just as well we're not switching off P1!).

@openstreetmap-trac
Copy link
Author

Author: iandees
[Added to the original trac issue at 7.36pm, Monday, 9th September 2013]

Cleaning aging tickets.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant