Modify

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#4223 closed enhancement (fixed)

Recognise when downloaded primitives are semantically equal to existing new primitives

Reported by: mjulius Owned by: team
Priority: normal Milestone:
Component: Core Version:
Keywords: Cc:

Description

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.

Attachments (0)

Change History (7)

comment:1 Changed 10 years ago by 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.

comment:2 Changed 10 years ago by stoecker

Resolution: fixed
Status: newclosed

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

comment:3 Changed 10 years ago by 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?"

comment:4 Changed 10 years ago by 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.

comment:5 Changed 10 years ago by 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.

comment:6 Changed 10 years ago by 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.

comment:7 Changed 10 years ago by 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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.