Opened 9 years ago

Closed 4 weeks ago

Last modified 3 weeks ago

#6914 closed enhancement (fixed)

Prevent combining ways where relations are not loaded

Reported by: mdk Owned by: team
Priority: normal Milestone: 19.12
Component: Core Version: tested
Keywords: combine, way, incomplete, public-transport-v1 Cc:

Description (last modified by simon04)

I got a huge problem when I merge two ways where JOSM din not download the ralations. This cause that some other relations has deleted ways as members.

This can happen if you download the members of a relation and combine two ways which are outside the boundig box (which means that their relations are not loadad).

Here is an step by step example:

  1. start JOSM
  2. File->download object...relation 1556696
  3. combine (c) two ways at the lower left beginning of the primary highway (110009332 and 88954933)
  4. download a boundig box including both ways
  5. There is now an error "The was 1 conflict detected"
  6. look at relation 1556773 (residetial with 17 members) which still contains the way 110009332 with 0 nodes!

Attachments (0)

Change History (11)

comment:1 Changed 9 years ago by mdk

Description: modified (diff)

comment:2 Changed 9 years ago by skyper

Keywords: way incomplete added
Summary: Prevent combiding ways where relations are not loadedPrevent combining ways where relations are not loaded
Type: defectenhancement

It is always on user's risk to edit with incomplete data. There for you have to download all references of a way before deleting or splitting.

I do not see any problem within JOSM and the conflict resulting on your edits is shown.

Only thing I can think of is a check weather you are editing on a complete area downloaded as bounding box or on an incomplete area with only some objects downloaded.

comment:3 Changed 9 years ago by mdk

Because combining ways is an implicit delete, why can't you show the same warning as on try to deleting a way, which is in an incomplete area? Just do the delete check on the ways which are choosen for deleting.

A general thing about usability in this case:
How dose a user should know when he could do such an operation without beeing affraid, to corrupt the data?
When I came into this problem, I saw two ways which belongs to some relations, both ways belongs to the same relations and had the same tags, so I decide to combine them. But I can't see, that one of the ways is also a member of a relation which is not already loaded.

So you mean, the user must know the internal algorithem when JOSM load missing relations of an element and when not? How dose a user should know when all relations are loaded?

I'm not a newbe in using JOSM, but I still have the problem, especially when I (must) work in areas where nearly eveything is a MP!

Last edited 9 years ago by mdk (previous) (diff)

comment:4 Changed 9 years ago by simon04

It's quite easy to run in such problems:

  1. Download a relation via Download objects, e.g., the boundary 943282.
  2. Note that the members are not part of any other relation, but in fact they are (e.g., download the way 60665540 to see the second relation).

comment:5 in reply to:  4 Changed 8 years ago by simon04

Description: modified (diff)

Replying to simon04:

It's quite easy to run in such problems:

  1. Download a relation via Download objects, e.g., the boundary 943282.
  2. Note that the members are not part of any other relation, but in fact they are (e.g., download the way 60665540 to see the second relation).

This occurred due to not using "Download referrers"

To display this warning, JOSM must be aware of potentially existing relations. I don't think that JOSM currently knows. To add this, JOSM would need to keep a history of how any object was added to the dataset. I don't think this is reasonable.

Instead, I suggest a simpler solution: Let's remove the "Download referrers" checkbox from the "Download object" dialog for the non-expert mode. What do you think?

comment:6 Changed 8 years ago by mdk

If you want to remove "Download referrers" in non-expert mode, then only, if "Download referrers" is set to true. But that will not solve the problem, because there are a lot of functions which load data without loading the referrers.

As far as I know, there is a function in JOSM to estimate, if all referrers to an object are loaded.
for a node: check if the node is in one of the bounding boxes the user has downloaded.
for a way: check if any of the nodes is compleatly loaded (see above)
for a relation: check if any member is compleatly loaded (see above)
Simply warn if an object is deleted, which not pass this check.

An other possibility is trying to download refferers before merging object (at lest for the object which will be deleted)

In general it would be possible to add a flag to any object, which will be set to true if explicitly all refferers has been loaded (which may be none). This flag will be set on downloading a bbox (see above) or if "Download referrers" is used. This way JOSM can easily warn if an object is about to be deleted and there may be unloaded referrers. (For memory efficeny you can use an int for 32 flags with getters and setters for modifying the bits)

comment:7 Changed 4 years ago by simon04

Keywords: public-transport-v1 added

comment:8 Changed 3 months ago by skyper


There were some changes about similar/same topic, lately. Not sure if it did cover your case ?

comment:9 in reply to:  6 Changed 2 months ago by mdk

I didn't get these problems any more - but maybe because of better warnings from JOSM and me obeying these warnings :-)

I think we can close this issue.

Still open is the problem mention in Comment 6, but there are still several other issues about this.

comment:10 Changed 4 weeks ago by skyper

Resolution: fixed
Status: newclosed

Was fixed within #18501.

comment:11 Changed 3 weeks ago by Don-vip

Milestone: 19.12

Modify Ticket

Change Properties
Set your email in Preferences
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.