Download all members of relations in the background

[quincylvania]

It's useful to have all members of a relation readily accessible, such as when zooming out to show the full extent of the relation. Rather than making the user manually download members (#5420), iD should automatically start downloading the full relation in the background once part of it is loaded for a tile. We might have to limit this by the number of members a relation has.

[slhh]

@quincylvania
Downloading the members of selected relations should have priority (part of #4903). In case automatic download of the selected relations needs to be limited, the user should be able to request the download manually (#5420).
Downloading any other relations can be limited, without generating such need for #5420.

[BjornRasmussen]

I don't think this is a good idea, because the advantage is small, and it would lead to iD being slower for many people, especially those with older computers.

[quincylvania]

the advantage is small

iD could do things like validate the continuity of large multipolygons, boundaries, and routes, as well as completely render relations. The usefulness of this depends on each individual mapper's needs.

it would lead to iD being slower for many people, especially those with older computers.

We wouldn't ship this if it makes iD slower. We'd have to figure out how to download and merge data without stalling iD on the main thread.

I'm thinking about this issue as more of a long-term goal than an immediate concern. It makes sense that a modern editing tool should have all relevant data available to the editor instead of them needing to worry about what's downloaded and what's not.

[pnorman]

#1201 (comment) suggests

Issue a /relation/id#/full query for incomplete relations after all map? queries have finished. This is equivalent to doing JOSM's "Download Members" for each incomplete relation.

[quincylvania]

Issue a /relation/id#/full query for incomplete relations after all map? queries have finished.

@pnorman As you also mentioned in the comment, this call can run into issues with very large relations. For performance, iD really needs to exercise more granular control over how many members are getting fetched at once.

Re: openstreetmap/openstreetmap-website#2348

[pnorman]

@pnorman As you also mentioned in the comment, this call can run into issues with very large relations. For performance, iD really needs to exercise more granular control over how many members are getting fetched at once.

Is it how many are getting fetched at once, or how many are added to iD's graph? The former would surprise me - is there much difference between requesting 500 ways 4 times or requesting 2000 ways once?

[quincylvania]

is there much difference between requesting 500 ways 4 times or requesting 2000 ways once?

I'm honestly not sure off the top of my head. I'm thinking about other optimizations. The relation/id#/full call returns all the members, but iD doesn't need to redownload entities it already has. We also don't necessarily need to fetch every member immediately if there are thousands. We can prioritize based on the index, role, and entity type.