Enhancement: Allow user to load incomplete relation members

[sogko]

Description
This enhancement is to enable user to load incomplete relation members, shown as <not downloaded> in iD.ui.RawMemberEditor.
This is a simple change but enhances the user experience greatly, especially in managing relation entities.

By simply calling connection.loadEntity(relationId), we can fill in the missing related entities (ways / nodes).

Demo
Checkout feature branch feature:load-incomplete-members and edit the following relations to demonstrate typical relation member sizes:

• Singapore's East-West Line (49 relation members)
  http://localhost:8000/#background=Bing&id=r445764&map=20.00/103.90306/1.31981
• Paris' RER B Train Route (352 relation members)
  http://localhost:8000/#background=Bing&id=r65074&map=19.00/2.56124/49.00988

Discussion

• Impact on performance
  • According to OSM Wiki, relations are not recommended to have more than 300 members. But of course, contributors may choose to ignore this guideline
• Letting user complete one relation member at a time
  • Instead of loading all of the relation members at one time, another possibility would be to load one at a time
  • But currently, there is no hint as to the full content of the incomplete member. In other words, user would only be shown <not downloaded> at first and possibly the role. The user would have to load each one of them until he/she finds the member that he/she is looking for.
• Placement of button
  • Currently, the enhancement has the button next to the form-label of a member, which might suggest that the action to be taken would only affect one member.
  • A better placement would be somewhere else where it suggests that the action will affect all members. (Like 'Complete All Members' or something to that affect)

Notes

• The buttons are currently styled with an interim icon ('geocode').
• jshint OK jshint js/id/ui/raw_member_editor.js

[pnorman]

So, performance wise, it depends on the API calls used

Both the relation full and way full calls have been moved to cgimap and are much faster than they used to be. Most wiki documentation probably pre-dates that, not that over 300 members on a route relation is a good idea, but the issues for those downloading them are much less.

The boundary for Germany, pretty much a worst case, took me under 30 seconds to download in testing. It used to time out at 5 minutes.

For loading relation members, there are three strategies to get all of a relation

• Use the relation/full call.
• Use the way/full call on each way
• Use the ways? call on all the ways, then fetch the missing nodes with the nodes? call.

Given the move to cgimap, I recommend the first. The others are only worth it if you already have most of the relation, something that will not be the case for big relations. For small relations, the overhead of relation/full is better, only having one API call.

[sogko]

@pnorman Thanks for the insight! Yeah you're definitely right, API calls does feel speedy. So it does make sense to get the full relation call while not being too worried of downloading massive data, to a certain extent i guess. (Question: for boundary for Germany, how large of a download are we talking about here?)

Though I have another concern with performance in terms of entities loaded into the iD.Graph.
(I just started going through the codebase, so feel free to correct me or add if I missed something).

From what I understand, connection().loadEntity() eventually triggers on('load.context') which merges the new data into the graph loaded in the client browser.

So would there be any concerns with accumulatively loading massive chunk of data onto the graph in terms of client performance (browser slowdowns/crash)? Or is that a matter of restarting the browser if that happens?

So far in my usage, I don't feel any penalty but I may have not used it for long enough.

Thanks!

[jfirebaugh]

Hey @sogko, thanks for working on this. This would be a nice feature and the approaches you and @pnorman have been discussing sound pretty good.

So would there be any concerns with accumulatively loading massive chunk of data onto the graph in terms of client performance (browser slowdowns/crash)?

There could be. It would be good to look at some numbers from heap profiling of large relations.

[bhousel]

This PR has gone a bit stale - @sogko are you still interested in merging this? I think it would be a really useful feature.

Are there any outstanding issues (other than changing the icon) that are holding this up? I could replace the icon with something that looks more "download-y".

[homersimpsons]

Any news on this ?

[bhousel]

Any news on this ?

Nope, news would be here.

[bhousel]

superseded by #5396