|
River Sázava (cz) is mapped twice (see example). According to the source tag one is an import from some database of waters, the second one has been created manually. |
|
One of the rivers is most likely a result of a local Czech DIBAVOD water import. DIBAVOD was donated by Czech government and I think the reason it was imported is because it contained a lot of water data that was still not present in OSM (like smaller streams etc.). While I do not know the import history by detail I think the "value" of new data was considered to be greater than the work planned to be spent on resolving conflicts. Since this is a bigger river you definitely should check it against UHUL ortophoto (in JOSM for instance) layer to see what the reality is and correct the map data. There still is lot of dupliates from DIBAVOD in general so if you can help to sort these out that would be great. |
|
First, you should check creation dates of the duplicated elements and blame the author who created the duplication without clean-up. If the duplicated data is coming from the external data import, then you should consider the import itself and possibly revert it when it is not done in the state of the art (see our wiki about imports) (perhaps the import was decided in this way and conflicts are solved manually by local contributors, check this point with your local community first). If you consider that the amount of duplicates is manageable and the imported data is valuable, then you have to decide case by case which of the duplicated way you want to keep and which one will be deleted: In the example you are pointing for instance, the imported waterway is qualified as a 'stream' and 'name' is missing where the manually surveyed version says it is a 'river', 'width' is '20' meters and the 'name' is present. Based on this example, I would say that the imported data quality is very poor (name missing), badly managed (they did not check for duplicates) and use wrong tags (20 meters wide waterway is a 'river', not a 'stream'). . In your position, I would check other examples of this imported data and revert it globally if there is no real added value but this should be done only after some discussion and consensus inside your local OSM community. |
I can imagine quite easily how this duplicity emerged. Also I have no doubt it should be removed.
The question how to merge the two ways with possibly minmal effort and maximal precision. What tools and procedures to use.
Not what to do, but how to do it.
I think there is no better way of merging than simply manually by hand in a visual editor. Sure it is a painfull task and that is why still many duplicates remain. I think the tasks to do would be:
I think both of these are hard to "automate", if this is what you ask for.