keep recently edited relations in membership dropdown for entire session#11588
keep recently edited relations in membership dropdown for entire session#11588
Conversation
|
|
||
| if (d.relation) { | ||
| recentlyAdded.add(d.relation.id); | ||
| allAdded.add(d.relation.id); |
There was a problem hiding this comment.
This would end up being a negative counter decrementing from zero.
There was a problem hiding this comment.
oh i think the choice of variable names is a bit confusing, adding doesn't mean creating a new relation, but rather adding a member to a relation.
for example:
- select
w7634775 - click + in the sidebar to add
w7634775as a member of any relation - pan somewhere completely different, and the relation you selected earlier will still be visible
There was a problem hiding this comment.
Ah, I see, so “selected” is probably a less confusing name internally. I hope users can figure out that that’s why these relations are lingering in the menu.
There was a problem hiding this comment.
If we think this will be confusing, we could exclude some relations that are always "local", for example type=restriction.
but as always when we hardcode random tags, it could cause even more confusion because no one can understand the logic
1ec5
dismissed
their stale review
Actually, this doesn’t seem to work for me. If I pan out of view, the relation list includes all the relations that aren’t in view, except for the ones I created.
k-yle
force-pushed
the
kh/add-relation-memory
branch
from
66ffb50 to
4024a5f
Compare
| // any relation that has previously been added will remain | ||
| // in the dropdown for the rest of the edit session. |
There was a problem hiding this comment.
Would this be more intuitive if we sort some or all of the relations by recency instead of relation ID, as proposed in #7964?
There was a problem hiding this comment.
yeah I think that would help, but a much more significant improvement would be openstreetmap/id-tagging-schema#1538 - this would filter out all the illogical options.
e.g. it would stop you from adding a road directly to a superroute, or adding a tree to a boundary relation, etc. etc.
| var _maxMemberships = 1000; | ||
| /** @type {Set<string>} relations that were added after this panel was opened */ | ||
| const recentlyAdded = new Set(); | ||
| /** @type {Set<string>} all relations that had members added during this edit session */ |
There was a problem hiding this comment.
why only added? maybe also keep ones where members were removed?
There was a problem hiding this comment.
If only added is intentional and desirable - then can you edit PR title?
|
From discussion: idea sounds nice, but there are some potential problems. What about turn restrictions? If someone adds bunch of no-left-turn with excellent iD turn restrictor editor "helpfully" listing them forever is not going to be useful. When user splits road with 50 bus relations they do not want to be haunted by this horde of Flixbus routes, probably. Maybe limit it to some subset of relations? |
|
yeah, I've changed my mind about this idea, after using this PR for several months.
So I'm happy to close this and revisit it after openstreetmap/id-tagging-schema#1538, when the list of relations will be significantly smaller1 Footnotes
|
|
Which in turn is blocked by ideditor/schema-builder#134 I guess that if anyone is interested in pushing them forward then commenting there on proposed code may be useful. |
3 participants
Closes #3622
The relation dropdown list now remembers relations that you've already added during this edit session. Even if those relations are no longer visible on screen.
Showing every downloaded relation as originally proposed in #3622 becomes pretty chaotic, I think this is a reasonable compromise which is still quite helpful