Modify

Opened 16 years ago

Closed 16 years ago

#1782 closed defect (fixed)

Relation Editor overwrites all changes made to the relation from the outside

Reported by: trompeter Owned by: framm
Priority: major Milestone:
Component: Core Version: latest
Keywords: relation split Cc: Gubaer

Description

When the relation editor is open and you split a way belonging to this relation in the JOSM main window, the splitted part of the way looses the relation when closing the relation editor with OK.

I think I know why it is like that:
1) When opening the relation editor a copy of the relation elements is generated for editing.
2) The split in the main window splits the way in two parts and adds the second part also to the relation. However, the relation editor is not notified about this change.
3) When closing the relation editor, the copy of the list of elements is written back to the data set, overwriting the change which had been made in the main window.

This behaviour is annoying and easily leads to errors in the relations. Currently I think of two possiblities to improve the situation:
1) Issue a warning or error when this scenario occurs
2) Add a notification mechanism to apply the split in the main window also to the data set in the relations editor.

Attachments (0)

Change History (10)

comment:1 by Schusch, 16 years ago

see #1748!

comment:2 by raffourtit@…, 16 years ago

No not a duplicate of #1748, possibly a duplicate of #1766
1748 relates to the fact that the server error is not kept on screen.
This one states that the user is allowed to make changes that lead to local data being modified in an (for the user) unexpected way.

in reply to:  2 comment:3 by Schusch, 16 years ago

Replying to raffourtit@gmail.com:

ok, maybe another problem but perhaps the same reason? Only a suggestion - that's why I wouldn't really mark this as a duplicate but only give a hint for the programmers to perhaps find a relation between the errors more easily ...

in reply to:  2 comment:4 by Schusch, 16 years ago

by the way, #1766 is marked as a duplicate of #1748

comment:5 by anonymous, 16 years ago

This is no duplicate of #1748. #1748 appears, when the relation is really wrong. This bug does not create wrong, but only incomplete relations.

comment:6 by xeen, 16 years ago

I've looked a bit into this and it's not as easy as I first thought it was. We need to update the relation for

  • SplitWays
  • Reverse Way (think of routes and forward/backward roles)
  • Deleting Nodes/Ways
  • Undo/Redo
  • … maybe more?


My first idea was to add a reference to Relation which links it to its RelationEditor if it is opened, but this has a few disadvantages:

  • Doesn't work for changes done while the relation editor was opened
    • Doesn't work for new relations at all because of this
  • We need to "understand" a ChangeCommand (i.e. split it into adds/removes, handle Reverse, etc.)
  • If more than one primitive is added, we need to find out the correct order (relations will be ordered starting with API 0.6)

We could simply notify all open RelationEditors, to work around the 1st issue. Still leaves us with the other two. We can add a dialog and ask to order them, like we do for "solve conflicts" now. Still leaves us with the ChangeCommand issue and this won't be simple because we need to care for many, many actions (so the actions not only need to handle the relation stuff but also the RelationEditor relation stuff! Sounds like fun…)

Thoughts about issuing a warning:

  • Maybe ok for the once in a year relation editing
  • Annoying if you edit a lot of relations
    • Make it "Don't Ask again"
    • Once checked, the situation is like it is now (i.e. it still sucks)
  • Virtually no effort to implement
    • Might work as a temporary solution?

To sum it up: A significant amount of work needs to be done to fix this issue properly and also be done in the future if a new tool is created or an old one maintained.

Thoughts about making it work instantly:

  • We currently stuff instantly for
    • tag editing
    • presets
    • deleting and adding primitives (apart from relations)
  • frees us from having to deal with the 'ChangeCommand' issue.
    • May also work for not too special tools that just add/delete stuff
  • still requires us fixing the "order" issue and the reverse way action (but latter should be accomplishable, it already works for oneway and the likes)

None of these really appeals to me. Relations are already complicated enough and I'm not too fond of the idea to have to deal with them twice (once for the data set and once for the relation editor).

If we want to burn in UI design hell we could also disable all tools while a relation editor is open :P

Suggestions welcome.

comment:7 by anonymous, 16 years ago

Summary: Splitted way loses relation when relation editor is openRelation Editor overwrites all changes made to the relation from the outside (was: Splitted way loses relation when relation editor is open)

comment:8 by anonymous, 16 years ago

Summary: Relation Editor overwrites all changes made to the relation from the outside (was: Splitted way loses relation when relation editor is open)Relation Editor overwrites all changes made to the relation from the outside

comment:9 by stoecker, 16 years ago

Probably we should unblock the Relationeditor (or make in configurable from the editor view) and introduce a "Your relation has changed warning" using the conflict dialog to handle the conflict.

comment:10 by Gubaer, 16 years ago

Cc: Gubaer added
Resolution: fixed
Status: newclosed

fixed in r1762. JOSM now opens max. 1 editor for each relation.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain framm.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.