Recognise when downloaded primitives are semantically equal to existing new primitives

[mjulius]

When an upload gets interrupted or JOSM gets terminated before the data is saved the next update will create duplicates of new primitives and they will be uploaded again as new.

Therefore, JOSM should recognise when downloaded primitives that have not been in the dataset before are semantically equal to existing new primitives and update these with the downloaded id.

[Gubaer]

IMHO, JOSM shouldn't do more than it already does. JOSMs merge logic distinguishes between "new" and "existing" object, the later being object with an assigned OSM ID. JOSM never merges an "existing" object onto a "new" object" and I think that's how it should be.

To be more precise, JOSM shouldn't do this in the standard download/update/merge-cycle. It would be helpful, though, if it offered a new recovery feature "Check for duplicate between new and existing objects" which one could use if JOSM crashed.

[stoecker]

That feature exists already in Validator and the recent changes regarding accuracy of the equal-check should now also cover this case.

[Gubaer]

That feature exists already in Validator and the recent changes regarding accuracy
of the equal-check should now also cover this case.

It does? Do you mean the "Duplicate Node" test? I rewrote this one yesterday and it doesn't quite do what I was thinking about.

I was rather thinking about a feature which

• selects the collection of new objects in the current data layer
• does a multi-get for these objects
• checks whether there is
  • for a node: an existing node at the same position
  • for a way: an existing way which is "equal" to one of the new ways is in this context a more complex predicate
  • for a relation: an existing relation which is "equal" to one the new relations

• displays a dialog "There are x new objects for which there is a duplicate existing node. Do you want to replace the new objects with the existing objects?"

[stoecker]

The validator duplicate node test catches this case even if it is not very comfortable. It is a very seldom case, so I don't think we need a special handling for it.

[Gubaer]

The validator duplicate node test catches this case even if it is not very comfortable.

As I tried to point out: no, it doesn't. It only provides a subset of the functionality requested for in this ticket. The submitter is asking for something which detects duplicate (semantically equal) primitives, not just nodes. This is beyond detecting whether two nodes are the same position and have the same tags.

[stoecker]

Yes, sure. But adding such a feature in a way it is really useful is lots of work and I doubt we really need it, as it rarely should happen that new nodes/primitives are equal to data on the server.

[mjulius]

Doesn't Validator also check for duplicate ways? After merging the duplicate nodes it should find those, too.

It might need a check for duplicate relations.