#6072 closed defect (wontfix)
Duplicate nodes in two unclosed ways (can't merge nodes)
Reported by: | wbski | Owned by: | framm |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core validator | Version: | latest |
Keywords: | Cc: |
Description
Well this used to work, but it doesn't now.
http://josm.openstreetmap.de/changeset/3784/josm/trunk/src/org/openstreetmap/josm/data/validation/tests/DuplicateNode.java
I am importing some CanVec data trying to merge overlapping way nodes at the boundaries of the import area. However, this fix seems to disable merging overlapping way nodes. This makes it pretty much impossible to efficiently import CanVec, wasting time doing manual node merges instead of dealing with existing data properly.
Attachments (0)
Change History (5)
comment:1 by , 14 years ago
Owner: | changed from | to
---|
follow-up: 5 comment:2 by , 14 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:4 by , 14 years ago
Well overlapping nodes are the way that ways continuing from one CanVec block to the next are combined. These are produced by the Federal Gov of Canada, and have support with Canadian users. There can be 100s of intersections along an import boundary, with streams and roads crossing the boundary. The removal of this from Validator will mean that people just won't bother to merge boundary nodes, having a massive impact on OSM quality in Canada. There should be some way to enable this! Maybe in the preferences? I agree it shouldn't be used blindly, but if all overlapping nodes in a selected area could be merged (along an import boundary), that would be the ideal solution to this issue.
comment:5 by , 14 years ago
Replying to anonymous:
... Any such intersection must be reviewed manually.
I personally made patch for myself that added the option to fix any kind of duplicates back. While it is true that this function is prone to destroy data if used mindlessly, it can be very useful if you first search for certain kind of nodes, for example search for "type:node (child type:way highway)", then you run validator on this selection and then you can automatically fix them (you will glue only highways this way, but not highways to anything else) - if you know what you are doing, you won't screw the data :). Plus, with this approach, you'll see which nodes are to be fixed (just doubleclick the list), so you have pretty good idea what it will do before pressing "Fix".
The quick hacky fix to enable this is simple:
Index: src/org/openstreetmap/josm/plugins/validator/tests/DuplicateNode.java =================================================================== --- src/org/openstreetmap/josm/data/validation/tests/DuplicateNode.java (revision 24302) +++ src/org/openstreetmap/josm/data/validation/tests/DuplicateNode.java (working copy) @@ -402,7 +402,7 @@ // never merge nodes with different tags. if (testError.getCode() == DUPLICATE_NODE) return false; // never merge nodes from two different non-closed geometries - if (testError.getCode() == DUPLICATE_NODE_UNCLOSED) return false; + //if (testError.getCode() == DUPLICATE_NODE_UNCLOSED) return false; // everything else is ok to merge return true; }
The validator is not a tool for fixing badly planned or badly executed imports. You should fix your import script to not create the overlapping nodes in the first place.
It is true that this used to work but we have reduced the number of situations in which the validator will automatically de-duplicate nodes for you because there were complaints about too many people just de-duplicating everything they found, thereby merging things that should not have been merged. For example if an import has created two crossing ways and each has a node at the intersection point then there is no way to know whether this is really an intersection or maybe a bridge/tunnel situation. Blindly merging these nodes via the validator makes the warning go away but at the cost of potentially introducing problems. Any such intersection must be reviewed manually.