Duplicate nodes on certain types of ways could be handled better #2708
Comments
Author: Richard 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! |
Author: NE2 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. |
Author: NE2 (by circled square I mean circle the larger square connected node symbol) |
Author: Richard If I get a chance. It's not impossible, incidentally, you can use the Inspector. |
Author: NE2 Email sent to talk list; waiting for the moderator to accept it. |
Author: Richard 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. |
Author: NE2 There doesn't seem to be any disagreement: http://lists.openstreetmap.org/pipermail/talk/2010-February/thread.html#48118 |
Author: NE2 Related forum thread: http://forum.openstreetmap.org/viewtopic.php?id=6407 |
Author: Wynndale 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. |
Author: NE2 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? |
Author: SK53 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. |
Author: gadget 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 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? |
Author: NE2 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). |
Author: Richard 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. |
Author: Richard (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" :) ) |
Author: NE2 I believe all the types of way that might have this problem are: 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 :) |
Author: NE2 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. |
Author: NE2 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. |
Author: Richard 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. |
Author: NE2 It might help you make sure it's fixed in Potlatch 2 :) |
Author: Richard Heheh. Actually P2 doesn't have any form of dupe node handling yet (just as well we're not switching off P1!). |
Author: iandees Cleaning aging tickets. |
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.
The text was updated successfully, but these errors were encountered: