Option "download relation members" do not download relations which this members belongs to

[anonymous]

When I downloading incomplete members of relation then are downloaded only members (ways). I have only information about that member belongs to two relations but really belongs to four. When I cut line then members are copied only to this two relations and two other relations are not edited - broken.

[Don-vip]

please make an effort to provide a better description of your problem by following the simple rules we ask on newticket and maybe adding a small example; I don't understand your bug report.

[anonymous]

Two boundary relations with 'outer' role members:

• A with 5 members
• B with 4 members

1.Download data from server just in "Downloaded Area" (see picture).

• to local dataset has been downloaded 2 ways and incomplete Relation A.

2.Use option "Download incomplete members of relation" for this relation.

• Now we have downloaded complete Relation A and all 5 ways (members).

4.Use Split Way (shortcut P) on Point X to split red way.

• Way has been splinted.
• From one red way now we have two ways (old shortened red way and new id:0 red way)
• Relation A has been automatically edited and contains now 6 members.
• But Relation B still contains only 4 members.

[Don-vip]

Ok thanks. As the data is a bit complicated, can you please attach your .osm file? It would save us time in order to reproduce the bug. Thanks.

[anonymous]

Same problem is when we download relation using:
​https://localhost:8112/load_object?new_layer=true&objects=r2920989&relation_members=true

We have straight way on left top and information about it is member of two relations.
But really it is member of six relations:
​https://www.openstreetmap.org/way/221018207

[skyper]

See #4142 and #4203.

[mdk]

I think splitting a way (or in general any edit operation) outside the downloaded area is always a dangerous operation, and should be prohibit in my opinion. I think it's not a good approach to add functions to JOSM to make such potentially dangerous operation safe, because when users start to edit outside downloaded areas, how can they be sure that the actual plant operation is now safe or not?

But nevertheless, here is an example what could happened, if somebody would use the extended functionality on a boundary[2] relation:

• Download an area which contains the way 124761787. This way is member of 15 relations. One of them is relation 2202162 (boundary[2] France) with 1256 members.
• Now the new "download relation members" will be called on the "France" relation. So he wants JOSM not only to download the 1255 missing members of the relation, but also all relations where any of these 1256 members are a member from.

I can not even estimate how much relations has to be downloaded, but because its a boundary[2], each member is also member of all higher boundary levels (for France: 3, 4, 6, 7, 8). Also France adjoin to Germany, France, Spain etc. So we need also to download all affected boundary relations from those countries. But they could also be members of other relation types. In this case way 124761787 is also member of boundary=political ("068-03", "Circonscription Est", "Saint-Louis"), boundary=local_authority ("Communauté de Communes des Trois Frontières") and some "disused" boundary types. But we had to do this with all 1256 members of the relation. Luckily we have several duplicates, but for admin_level=8 we will normally have one or two unique relations for one way.

Can somebody calculate how much relations we had to download in this special case?

[skyper]

JOSM renders the download area.

Only find "split way" and "change direction of way" problematic and in both cases downloading parents of the way in question should be sufficient.

I often only need to download all members of only one relation like checking a multipolygon for consistency or getting information about a poste code boundary.

Even when adding boundary[10] I do not want to download all members of the touching boundary relations of Germany and France (+ all lower boundary) but only one or two members.

It might be useful as additional option but I still doubt it and would prefer warning/automatical download before problematic actions.

[mdk]

Also dangerous are "Delete way" and "Merge ways".

I see the problem with "downloaded area" when dealing with relations.

What about an additional flag in JOSM on each way: allRelationsDowloaded (or more general: on each objects a flag allDependencysDownloaded)
When a way is downloaded by the "download area" function, all related relations are downloaded too, so the flag will be set to true. When downloading additional members of a relation, this flag will be set to false. When executing an operation (on ways) which has impacts on relations, they should be rejected, if allRelationsDowloaded is not true. We need an additional function to download all relations of an object (node, way, or relation). This would be enough in the example to apply this function on the "red" way in the example before splitting this way.

Alternatively JOSM can automatically try to download missing relations if a dangerous operation is performed on an object which dependencies are not completely loaded. But I would prefer a warning, so the user knows what he is doing unless we can 100% ensure that operations which could have impact on related objects are only executed if all related object are loaded.

[mdk]

A quick look into JOSM source: OsmPrimitive.flags uses only 13 bits of his 16, so this flag could be added without impact on memory usage.

Perhaps using this flag can replace methods like Command.checkAndConfirmOutlyingOperation() with more general checks.

[mdk]

After looking into the code I made some whitebox testing. Here is an interesting result:

Because delete operations are only checked against the bounding box, here is another potential dangerous situation:

1. Download an area. If you try to delete a node outside the bounding box, you get a warning from Command.checkAndConfirmOutlyingOperation(). [ok]
2. If you move the node into the bounding box no warning is shown, because moving a node is not dangerous for related objects. [ok]
3. Delete this node. No warning is shown, because this node is now in the downloaded area, but other ways or relations which also use this node are damaged, when they are not downloaded yet. With the proposed new flag, this situation can be detected easily. [error]

You can also delete a whole way without any warning, if you fist move all nodes from the way outside the downloaded area into the area.

[skyper]

Replying to mdk:

After looking into the code I made some whitebox testing. Here is an interesting result:

Because delete operations are only checked against the bounding box, here is another potential dangerous situation:

1. Download an area. If you try to delete a node outside the bounding box, you get a warning from Command.checkAndConfirmOutlyingOperation(). [ok]
2. If you move the node into the bounding box no warning is shown, because moving a node is not dangerous for related objects. [ok]
3. Delete this node. No warning is shown, because this node is now in the downloaded area, but other ways or relations which also use this node are damaged, when they are not downloaded yet. With the proposed new flag, this situation can be detected easily. [error]

You can also delete a whole way without any warning, if you fist move all nodes from the way outside the downloaded area into the area.

See #10999 is exactly about this problem

[skyper]

Replying to mdk:

A quick look into JOSM source: OsmPrimitive.flags uses only 13 bits of his 16, so this flag could be added without impact on memory usage.

Perhaps using this flag can replace methods like Command.checkAndConfirmOutlyingOperation() with more general checks.

See #18959 for similar thoughts.