Is a pull request or issue opened already for that?
(only tangentially related to this discussion but)
PR, no, issues, lots - around various different ârelation issuesâ in iD. These include
- visibility of relation id (10184)
- being able to tell routes from ârelations of relationsâ (10108, 10343, 9942)
- Not being able to load a relation at all (11340)
There probably are also ones for:
- Not being able to tell relations apart because only the name is shown (also 10184)
- The general lack of fields when showing relations (again, sort of 10184 again)
If you search the iD open issues list for either SomeoneElseOSM or ârelationâ youâll find them.
I tend to use P3 so donât tend to get any of the above issues myself, but do fix gaps in relations when they are created by users of other editors (I got an email about 4 this morning).
Edit: Added some links to relevant iD issues.
I would really like to understand how iD would be causing pushback from removing descriptive non-names. 
Specifically for the from/to tags: iD does use them, except if the name is formatted like a ptv2 pseudo name. For example in the relation of the original post, the route now has name as âJakobswegâ, from as âBrochenzellâ and to as âNonnenhornâ, which results in the following label:
The points you mention seem to be unrelated to the specific issue thatâs discussed in this thread, arenât they? But to quickly address them: visibility of relation id â You can see it by open the history panel (Ctrl + Shift + H) after selecting the respective relation. being able to tell routes from ârelations of relationsâ âIâm not sure I can follow: routes will always be labeled as Route (or the specific route type like âHiking Routeâ in the example above), and meta-relations will either be labeled just as plain âRelationâ (or again by their specific type like âRouter Masterâ), isnât that sufficient? Not being able to load a relation at all â Normally relations are automatically loaded through the respective API map call. If the relation is not in the current view, one just needs to scroll to where the location where the relation actually is mapped, or alternatively it can be manually loaded by entering the relation id into the search box. Not being able to tell relations apart because only the name is shown â As mentioned above: iD will show more than just the name, and in the unlikely case that there are two (or more) relations that end up with the exact same label, the relation iD is shown in the hover-text to disambiguate them. The general lack of fields when showing relations â There are of course already the fields for the important tags (like for example from and to), but it could be well the case that some tags are not yet included in the id-tagging-schema. But in order to address those, weâd need to know which ones are actually missing, so: could you please be more specific, ideally in form of an issue (or PR 
) on github? Yes, some of these workflows are different from what youâre used to in Potlatch and might require a few additional clicks. If P3 works well for those cases, thatâs great!
1 Like
(with mod hat on)
Iâve moved a few posts out of the previous topic to here since itâs not really anything to do with âhow to tagâ.
2 Likes
What I was thinking about was this relation. My change changed the name from âTrans Pennine Trail (Selby to Hull)â to âTrans Pennine Trailâ and added âfromâ and âtoâ tags. That got changed back (by a JOSM user, not an iD user). See the discussion there, which referred back to a previous forum topic, which in turn refers back to mailing lists here and here.
So it be clear the âissue where I had (very polite) pushbackâ did not involve iD - I was misremembering that bit. However, the remaining bit of the sentence âiD really does not make whatâs there clearâ is still very much true.
Iâve updated my previous post with the relevant iD issues of mine that Iâve added before about this.
The solution is (notwithstanding screen re-estate) simple - always show the relation object id.
Edited to add: Cludges like âshow the relation id occasionally on hoverâ arenât an answer. Things on hover arenât discoverable, and âoccasionallyâ means that it is not a reliable mechanism.
2 Likes
Just to add another example, these townlands fell out of the database last night:
-5994043 | Codrum
-5986752 | Lackaduff
-5984244 | Gurteenroe
Iâve filled in the gaps in 175234630, using overpass queries from a couple of days ago like this.
There are a couple of issues here. One is that there (based on the changeset tags) there was no warning to the user that theyâd broken relations. Another is that you canât reliably select a way in iD - this node is part of three, one of which should be part of two relations and two of which shouldnât be. I can click on the node, but canât see in iD even that it is a member of multiple ways, let alone cycling through those to see what relations each is a member of. @Minh_Nguyen (I think) did post a cludge somewhere in this forum that allows you to select everything but as the help in iD isnât searchable I obviously canât find that.
In another example, this national park also fell out of the database last night.
Thatâs harder to detect, because no relation was changed directly; an object that was a member of a relation was changed in such a way that made the geometry of the relation invalid. Itâs even harder to deal with in an editing session, since (in this case) the userâs edits are fixing the route of that very relation; they know that their edits are correct (here âit goes west of the quarry not eastâ); but there need to tidy up some âpreviously wrong thingsâ (here, the old path of the relation down the river).
If the node belongs to multiple ways, itâs gray instead of white. Select the node, then press CtrlUpArrow (ââ on macOS). The parent ways are listed at the top of the left sidebar, where you can select or deselect the way you want to interact with. You can also use the same shortcut but with the down arrow to select all the nodes that belong to the selected ways. These shortcuts are listed in the keyboard shortcuts panel, accessible from the Help panel or ?.
This workflow is inspired by Potlatch, so Iâm confident youâll get the hang of it eventually. 
Potlatchâs W accelerator key lets you cycle through the parent ways repeatedly, but the corresponding \ key in iD only cycles through parent ways for the purpose of deciding which way to follow when navigating along the way using Ctrl[ and Ctrl]. I think the âfocusedâ way should be used for more.
At some point there does need to be a more direct affordance for selecting overlapping elements, even if they donât overlap, since itâs an even bigger usability issue in OpenHistoricalMap. But I think keyboard shortcuts are kind of destined to be arcana that only power users can learn. Something visual would be a lot nicer, like the old pie menu that iD used to have, or a 2.5D layer view that you can toggle on and off, but I havenât thought through these half-baked ideas yet.
(By the way, the title of this topic focuses on relations, but the discussion seems to be broader than your concern â duly noted â that iD doesnât blast big numbers at users all the time.)
1 Like
(Iâm sure Iâve raised this in github previously but for completeness in the forum).
How do you expect someone to discover that? Things that I tried included:
- Looking at the options available on-screen. There is nothing.
- Trying to search the help: There is a â?â, but if I click that and use normal browser search (^F) nothing is found. There is no option to view the help as a web page, or download it in any searchable format (even as a text file).
- Should I stumble into âkeyboard shortcutsâ (and to be clear, I am not looking for a keyboard shortcut, just how to do something) I see a page with some pictures that are too small to read and some words. In there I can search for âselectâ, but âctrl uparrowâ is not not listed. âbackslashâ is listed as âSwitch parent wayâ, but no change occurs that allows me to view relation membership.
I have no idea what that even means in the context of iD because the word âfocusâ does not appear on either help page.
Iâd absolutely agree with that. As I said, Iâm not looking to âuse a keyboard shortcutâ here; Iâm looking to âselect one of several parent waysâ. iD has a right-click menu; logically that (or a replacement for that) is where this should be.
Making relation numbers visible is key to editing OSM anywhere that you need to add anything to a relation. If you want a silly example, try editing this way in iD. Lots of those 110 relations have similar names. For example, do I want " St. Andrewâs (8491177) (as outer)" or " St. Andrewâs Parish (11196534) (as outer)"? Arguably neither should be in OSM at all, but that is an entirely separate issue - iD needs to deal with the data as it is, not as we would like it to be.
Even somewhere more normal is a problem:
Yes, I can drag the vertical divider to the right to see more of the names, and then back to do the actual editing, but its a chore. The error I was fixing was caused by the previous editor selecting the wrong EV1 relation from
was it surprising that they picked the superroute by mistake?
Even worse after theyâve picked the wrong one, they can over over the relation that they have just added and it will show as âcorrectâ when it is not because iD displays route relations incorrectly recursively. Iâm sure that Iâve logged that at github, but the nearest a search finds is 9942 which actually doesnât explain this part of the problem.
To be clear, I was referring to the lower-right corner of the Keyboard Shortcuts panel. The panel depicts keys as keycaps, so that the user can hopefully recognize the keys by the labels on their physical keyboard. In practice, this is hit or miss: many non-English speakers use virtual keyboard layouts or their physical keyboard has other nuances that break this assumption. Anyways, hereâs what it looks like for me, when using macOS with its think-differently keyboard layout:
(I mixed up my forward slash and backslash earlier. Wouldnât be nearly the first time. Iâve edited my post.)
None of this is specifically about relations. The keyboard shortcut for selecting parent ways is useful for unearthing buried overlapping ways, which could of course be members of relations like anything else. I brought up the shortcut because you seemed to be asking me about it.
Try selecting a shared node (one of the gray ones) and pressing backslash a couple times to see what I mean. When you select any point, line, or area, it glows red and pulses to let you know that any operation you do will affect that element. When a way is focused but not selected, it also glows red, but fainter and without pulsing, letting you know that the âJump to previous/next/first/last nodeâ shortcuts will travel along that way and not the other one. In the screenshot to the right, compare the boundary line to the shared node:
As far as I know, this behavior is completely undocumented. I only discovered it by stumbling upon the code for it! Distinguishing two kinds of selection by brightness might not discriminate against colorblind users but itâs unfriendly to everyone. Although this behavior is inspired by Potlatch, Potlatchâs W selects the way instead of leaving the node selected. It doesnât distinguish between selected and focused ways, except that it remembers which connected way you last selected so that W can cycle among them.
In addition to the labeling change I suggested, iD could actively prevent the user from adding a node or way directly to a superrelation (not necessarily a superroute, could be a route or route_master) by omitting it from the dropdown list. On the other hand, as soon as one stray relation member makes it into a route or boundary relation, this behavior would make it more difficult to sort things out. So it probably needs some additional thought beyond what Iâve outlined.
Have you had a chance to consider this question about how someone other than yourself would use these numbers? As I see it, exposing the numbers isnât completely out of the question, but if thereâs a general problem to solve, it sounds like an incomplete solution.
1 Like
I was kind of expecting something to change in the left-hand side of the screen, but it doesnât. Instead the selected thing changes in the right-hand side (maybe). If youâre zoomed in on this node something imperceptible changes but only when you zoom right out to see where the parent ways diverge do you see a difference.
Given the state that OSM data is in in some places, that would be a problem - far easier just to show the difference in the UI.
Someone working with relations needs some way to tell apart similarly named relations like in my first screenshot above. It doesnât matter if they donât fully grasp what a relation ID is** , they can see that the numbers are different and that means that they will know it is a different relation. Currently iD actively hides this from them.
Edited to add: After using âblackslashâ to swap between parent ways, how do I know anything about the newly selected parent way? What actually is it? What tags does it have? How do I do something with the new (selected? focused?) parent relation?
** though I suspect that most will - they interact with OSM, in which IDs are prominent, and only then click edit to go into iD, where they are hidden.
1 Like
That sounds like that version of iD should be blocked from uploading changesets to me.
Short answer is you canât. If you want to interact with a way, you need to select it, not focus it. Thatâs what I meant earlier by this functionality being underutilized. At least the F key (for following another way â same as Potlatch) should follow the focused way instead of throwing its hands up. When Potlatch encounters concurrent ways, it happily follows the last selected way, which is an invisible version of that âfocusedâ state.
We donât have hard numbers on this, but I strongly suspect otherwise. Most users encounter relations in the course of attempting to edit something else, including in the case that prompted your post. The mapper probably didnât have either NCN relation open in a browser tab when updating the physical infrastructure at that intersection.
By your own reckoning, you deal with relations a lot more than the average mapper, since your tool spits out relation IDs that you then go investigate. This is a valid use case, but we need to consider the broader user base.
OK, so what youâre really saying is that the user needs to know whether a relation in the dropdown menu is already part of the same hierarchy. Iâve proposed to somehow 
mark already related relations so the user can tell that something strange would happen if they choose it.
Unfortunately, I donât think we can completely hide already related relations from the list because of some PTv2 edge cases like loops or backtracking. But certainly if thereâs any case thatâs guaranteed to be an error, we should hide it from the dropdown.
Iâm sorry if Iâm being hard of thinking here, but how do I do that - reliably select one way rather than another at a shared node, when itâs quite possible that thereâs no name, the tags are the same (think natural=heath) and most of the geometry is offscreen?
Ways tagged natural=heath are areas by default. Normally, you donât even need to select the shared node. You can select the area directly by clicking on the colored band within the area â the green parts in this screenshot:
If this differs from what youâre seeing, make sure you have Partial Fill or Full Fill enabled in the Style Options section of the Map Data pane. If you prefer wireframe mode for its relative lack of clutter, you can quickly toggle it on and off using the W key.
You would still need to select the shared node and then select its parent ways if the areas overlap rather than just touching. Even in that case, sometimes you can still select the areas directly, since some areas, such as indoor areas, have thinner or thicker colored bands.
1 Like
So in the case of https://www.openstreetmap.org/node/3356978826 I can reliably click on the east and west side of it and get the east or west farmland polygon? What about the stream? In my experience clicking on the way doesnât always get the one linear feature of three, although it does seem to here. What if there are two overlapping linear features?
(and no, I donât condone this sort of mapping, but it happens 
)
Yes, hereâs a gif - I added LEFT/CENTER/RIGHT=YES tags to make the selection clear.
Trying to select an overlapping node/way is really frustrating though, in my experience.
2 Likes
Thatâs when the Ctrlâ shortcut comes in handy. It isnât terribly discoverable and doesnât work if someone has helpfully disconnected the ways without offsetting either way, but itâs still better than nothing.
To elaborate, since I havenât actually proposed this yet: clicking where there are multiple features underneath would still select one of the features, but it would also pop up a pie menu that lets you choose one of the other overlapping features. Each button would represent one of the overlapping features with a tooltip that provides more information. Clicking it would select the feature. If you picked the wrong one, you click another one from the menu.
If you didnât check out iD back in the early days, it originally put the context menu in a pie menu. Pie menus, or radial menus, are a theoretical favorite of usability researchers, because every operation is an equal distance from where you clicked and avoids covering up the space directly around that spot. iD ultimately abandoned it in favor of a conventional menu after gaining one too many items. But a conventional menu would be too obtrusive for a palette that pops up automatically after a little delay.
The other problem with iDâs implementation was that the available operations kept changing, shifting the items around, so you couldnât develop any muscle memory. That may be less of a problem for a âdisambiguatingâ menu that only pops up when there are overlapping features.
1 Like
While I believe a popup menu is the way to go for overlapping element/relation selection (not quite sure when Vespucci got that, but it was already there in 2010), a radial menu is just going to be hopeless. Clicking on the road in front of ZĂŒrich main station will give you 44 entries, and Iâm sure that isnât any where near a record (yes Iâve contemplated many times to add a toggle around the lines of âHide xxxxxxx PT relationsâ).
I was thinking it would be just for overlapping points/lines/areas. Youâd still have to click on the way to see which relations itâs a part of, but you could click through each way without the menu going away, since itâs more of a floating palette. Granted, this wonât scale in the case of OHM, where itâs common to have a dozen or more overlapping, connected ways. For that there could be an overflow menu.
Or maybe just a standard context menu item for selecting everything under the cursor, revealing the infinitely long list of features in the sidebar. That would be simpler, but there would be no way to cycle among the ways by clicking.