Keep relations in relation membership dropdown for entire session

[1ec5]

The relation membership dropdown only displays relations within the current viewport. As soon as you pan away from the relation’s existing members, the relation disappears from the dropdown. By contrast, in Potlatch (1 and 2), the list of available relations keeps growing as you pan around. I think iD should adopt Potlatch’s behavior, keeping all loaded relations in the dropdown until leaving iD.

Very often, I need to tag a place POI as a boundary relation’s label or admin_centre. In iD, this entails zooming out so that some part of the boundary is also visible – generally only possible for villages, because nothing is editable beyond a certain zoom level. Alternatively, I can drag the POI to the boundary and tag the relation membership with both features in view, but then it’s difficult to put the POI in exactly the right place again. With this issue fixed, I could pan to the boundary then pan back to the POI and add the relation membership without relocating the POI. There would be less need for #3487.

[bhousel]

Doesn't that list get kind of unwieldy? I'd think that in places with multipolygons or turn restrictions or road routes, the list of "seen" relations would easily grow into the thousands.

[1ec5]

It can get unwieldy. Thousands would be overstating it a bit. Even with my hours-long, roving edit sessions at z18 in rural counties where all roads are part of route relations, Potlatch’s relation list rarely exceeds a few dozen relations. (Although maybe that means I need to map more turn restrictions in my area!)

Sorting relations by distance from the viewport, as iD seems to do currently, would at least push the most relevant relations towards the top. If performance is a concern, I think it would be fine to “evict” relation types that tend to be very local (such as turn restrictions) and prioritize persisting relation types that may have distant members (especially boundary relations). Route relations probably fall into the latter category: the user might map a bus route relation by its stops, at least initially.

[bhousel]

I don't think "thousands" is overstating it. Here's a list of 117 relations at z16 over lower Manhattan. I haven't even panned yet, just loaded the map initially.

https://gist.github.com/bhousel/eb9ceb75c51c46a7e3601c9c01b23bcd map=16.19/40.71985/-74.00277

to generate:

relations = id.intersects(id.map().extent()).filter(function(entity) { 
    return entity.id[0] === 'r' ;
});

all = relations.reduce(function(acc, r) { 
    acc[r.id] = {type: String(r.tags.type), name: String(r.tags.name)}; 
    return acc; 
}, {});

JSON.stringify(all, null, 4);

My quick impression of this list is that it's a lot of messy stuff. Some have names, and some don't. Some don't even have types. And I know that the routes here (especially bus) are very incomplete, and lots of turn restrictions missing. There are a mix of buildings mapped as multipolygon, and a handful of building relations (and you know if that ever catches on, the number will increase dramatically).

And that's just the current view. iD today shows them all in the relation dropdown:

So I'm not really sure what to do with it.

I'm thinking of how I would want to use this feature.. Yes I sometimes want to add a highway segment to an off-screen route, but that's about it.

We could replace the '+' with a field to let the user pick what kind of relation they want to add to, only support certain kinds, and filter the list. Also #2283 is the potentially serious bug nobody is talking about that we should probably solve first.

[1ec5]

z16 over lower Manhattan

That's a pretty extreme case, in my opinion. But as for how you'd use this feature, do you disagree that adding admin_centres or labels to boundary relations or bus stops to bus route relations is impractical currently?

[1ec5]

One compromise would be to avoid deselecting the currently selected feature when panning, so that you could still pan to the boundary relation’s outer way, select it, then pan to the admin_centre/label POI, then add the POI to the relation. Still inconvenient but no longer impractical, and it passes the Manhattan stress test.

[bhousel]

But as for how you'd use this feature, do you disagree that adding admin_centres or labels to boundary relations or bus stops to bus route relations is impractical currently?

I defer to your judgement, those are mapping tasks I'm not familiar with. I do agree we need to find a way to let people add features to off screen relations.

One compromise would be to avoid deselecting the currently selected feature when panning,

Yes we should do this.. The deselecting behavior is annoying.. I'd like to keep things selected and add an easy way for people to click a button and ease the view to show the selected feature.

[slhh]

@bhousel The add relation could show the following dropdown:

• "New relation" -> as currently
• "Search nearby relation" -> second level type selection like "New relation" -> use type dependent search distance
• List of recently visited (shown in the inspector), added or removed relations independent of their distance.

Btw, the Manhattan street test doesn't seem to be hard. Some time ago I let overpass count route within an equally sized bounding box around some cities: San Francisco:~400 New York : ~2000 Düsseldorf (Germany): ~20000 Other German cities were not such extreme, but still more routes than New York with 1/10 of the inhabitans. This might explain why we have had much more problems with relations which were damaged by iD.

@1ec5 A workaround to add far away members does already exist, but it is nasty. I have managed to add a street in Vienna to a boundary in Berlin as a test:

• goto Vienna, select the street,
• add a new relation as dummy
• select the new relation
• pan to Berlin (a relation isn't automatically unselected)
• add the Berlin-Boundary as a parent relation to thr dummy
• go back to Vienna, select the street again
• add the Berlin-Boundary as a parent relation to the street (it is now visible, because it is already indirectly related to the street.)
• select the Berlin-Boundary, remove the dummy relation from members
• select the street again, delete the dummy relation

[1ec5]

One compromise would be to avoid deselecting the currently selected feature when panning,

Yes we should do this.. The deselecting behavior is annoying.. I'd like to keep things selected and add an easy way for people to click a button and ease the view to show the selected feature.

Should I open a separate issue tracking this change?

[bhousel]

Should I open a separate issue tracking this change?

Yes, I think I can improve this 👍

[1ec5]

4128

[NopMap]

In my fork of iD I have implemented a very simple solution to this problem:

• whenever you select a relation in the inspector, the relation is cached
• when you click the add-relation button, the last cached relation is shown on top of the list, directly after "new Relation"
• this is done regardless of whether the cached relation is inside or outside the current map extend. If it is outside, it is loaded.

This way it is rather simple to extend distant relations, you only have to locate and select them once. If you need to add multiple ways, you don't need to search the list every time.

You can try it out on www.wanderreitkarte.de. It is still in testing. I also did limit the list to route relations. That is not a bug but the focus of my fork. :-)

[BjornRasmussen]

This has made it very hard to create bus route relations, since the newly created bus route relation can't be given far away stops. I think that the caching selected relations is probably the best solution to this.