If the routes are concurrent at this location, then you can select the shorter way, search for âLondon cycleâ, then hover over the search results until you find one that highlights the gap in red as opposed to blue. Route 0 is a member of this superrelation, so both of these relations technically have a gap in them, thus the same exact highlight:
You wouldnât know this, but the relation list is sorted in ascending order by relation ID. Generally the superrelation would be further down, but thereâs no guarantee. iD could sort the list by something smarter than relation ID, such as (downloaded) distance or most recently used. Even better, if the adjacent ways are members of a given relation, it should sort higher than any other relation in the list.
Not sure what youâre referring to. Do you mean iD was in an unfocused window? Whether a tooltip appears will depend on your operating system. I donât think a Web application would have much if any control over that.
Is that documented anywhere? If so, what buttons do I press in the iD editor to view that documentation?
No they do not. As can be seen from the screenshot above, what is displayed on screen is identical. What you might be saying is that iD has pretended that the âfromâ and âtoâ tags are part of the name and has extended the name off-screen in a way that I canât see. Thus it knows the names are different but I do not, since it has not shown me the parts of the names that are different.
Agreed, and that is why âonly displaying information in a tooltipâ is a bad idea.
Potlatch has two keypresses here. âWâ selects the parent way; it doesnât cycle. â/â is used on junction nodes, and cycles among ways. If you press â/â on a non-junction node it wonât do anything.
On reflection maybe a single keypress could have covered both scenarios.
Yep. Potlatchâs selection state is âway+nodeâ (controller/SelectedWayNode.as), so there is always the concept of âI have selected node x as part of way y".
Originally originally, as in my very early prototype of iD, it was a fairly standard popup menu rather than a pie menu, I think. But that was a very long time ago!
There is some documentation under in the Relations section of the Help panel (accessible from the right side of the map), but it doesnât explicitly discuss the colors on hover and what they mean. That would be a reasonable change request.
I think weâre talking past each other. Youâre focusing on the list of current parent relations, while Iâm trying to point out that what you actually want to look at is the dropdown menu when clicking in the âChoose a parent relationâ combo box. In that dropdown menu, long items wrap onto multiple lines. Instead, the main list truncates long items, showing an ellipsis to indicate that you can see more text by hovering over the item or resizing the sidebar. This design keeps the row heights regular, avoiding mishaps when repeatedly clicking the button to remove members. But maybe line-wrapping the labels would be a better tradeoff.
Tooltips are an established element of Web applications and webpages, and tooltips are also an established affordance for expanding truncated text on most desktop operating systems. Granted, they arenât perfect for every situation. In order to weigh the alternatives constructively, you need to elaborate on your reason for disfavoring tooltips. Do you juggle multiple windows including applications other than your browser? Do you use a touch input device that canât hover over anything? Does the delay before showing a tooltip try your patience? Do you use an older browser that autohides the tooltip before you have a chance to memorize the long number in it?
Hence the rest of the sentence that you quoted. Tooltips are a standard approach for overflow content when truncating a preview. I disagree that iD relies solely on a tooltip to expose the full label to the user. The full label is visible in the relation chooser dropdown menu as well as the various fields when you click on the relation to select it. It just isnât as convenient. Web applications always have to make compromises because they canât scroll like ordinary webpages.
The request here is to make the full label visible upfront at all times and never show it partially. The motivation is to optimize around a workflow that has never been fully described, so I can only guess as to whether it would be a worthwhile improvement. What I do know is that replacing truncation with line wrapping would make the list rows irregular, making it more difficult to download a series of relations or remove the selected feature from a series of relations without accidentally changing relation roles to random values.
Then again, knowing the history behind this conversation, itâs clear that just showing the full label would only lead to more complaints from the same individual. The underlying request is still to show relation IDs everywhere. Itâs a fairly common request, but it only comes from a small group of mappers who donât use iD as their main editor (probably for completely valid reasons). If the color-coded highlights are unintuitive, imagine what an eight-digit-long ID would mean to the vast majority of users.
This is just my opinion. But as someone who does use iD as the main editor, I would like to think I have an interest in iD continuing to be iD and not turning into a poor imitation of another editor. As much as I truly miss Potlatch and its elegant modeless paradigm, you wouldnât want me to blindly implement its UX design in iD, since I canât even get AIR to run on my computer anymore.
I also regularly tutor newcomers in making their first contributions to iD. This gives me some insight into how normal people experience the project as a whole. Last week my students asked me to explain how to map bus and trail routes, and I obliged. I only mentioned element IDs later, as part of explaining the raw data model so that theyâd be prepared to write their own Overpass queries. If we take the stance that they need to know how OSM works under the hood before they can touch the map, then weâve lost as soon as they set their eyes on the toolbar with those three fake element types, Point, Line, and Area.
Iâm genuinely not seeing this - can you explain what buttons I need to press to see it? In the example above (now fixed) there was a gap in a relation. I donât know the relation number, I just know that iD displays it as âGB:London Cycle Networkâ, and that that label is not unique. You explained above that I can search by [whatever iD is displaying as a label - I actually donât know what fields that can be composed of] and find a relation with a gap in it, and add the way to that.
The next questions are:
How do I know if that way should be a part of that relation? The only thing that I know about the relation is that the way that I have selected is not part of it, and it is [presumably?] nearby. I have no idea whether it needs a role of inner or outer if appropriate (not here) or a route-specific role (also not needed here as it turns out).
How do I see what the various tags on that relation are set to?
How do I view that relation in an OSM browse window to look at the rest of it (maybe it is complete, maybe it is just a work-in-progress and maybe it should be deleted because it is a duplicate of a âcorrectâ relation)
If I decide to just guess and add one, I see an extra relation in the list for the way, but have no idea which was the one that I just added because all the labels that iD displays here are basically the same (and I donât know what OSM fields they correspond to).
I can click on the various relations for the way to see the fields in each but without knowing which one I just added that isnât helpful.
The dependency on AIR makes it extremely difficult, and iD does a lot that Potlatch doesnât do (and not all of what iD does is a step backwards). However you really would benefit from seeking out somewhere that you can run P3 and look at the relation editor in there. From a UI point of view it is vastly superior to iDâs undocumented flashing colours. Things like âload relation by IDâ work reliably (in iD, tat does not). Switching between single-line and multi-line display of object details occurs at sensible times and doesnât rely on wasting screen space. You have actual fields with actual tags in them for relations, not labels composed of who knows what - such as in this example bizarrely the label is the cycle_network tag(!).
Indeed - that is a perfectly sensible approach for someone who is absolutely new to OSM, but as you say they will need to know more as time goes on. iD should allow them to see object IDs, perhaps in a similar way to how JOSM does - off by default, but able to be turned on.
Underneath the list of parent relations, thereâs a combo box for adding the selected feature to another parent relation. If you click into that combo box, a dropdown menu appears. You can type in something to filter the dropdown menu by any text that appears in the label, regardless of the raw key that the label is based on, or alternatively the relation ID. By typing in âLondon cycleâ, youâd see a menu that includes a few different routes that belong to the London Cycle Network.
By hovering over the menu items â I know, I know â you can see at a glance whether the way is a member of the relation yet. There are some bugs with this display that weâve already hashed out in the issue tracker ad nauseam. You may have also seen that thereâs work in progress toward more explicit relation validation, including for detecting and fixing gaps in route relations. Notably, this does not depend on displaying relation IDs so prominently.
For your awareness, the label is currently based on the preset name, name=*, network=*, cycle_network=*, ref=*, direction=*, from=*, to=*, and via=*. This is intentionally not documented as anything to do with relation memberships, because itâs actually part of a global heuristic for labeling any feature.
The set of keys may change, especially as networks get their own dedicated presets. For example, someday the LCN will have its own preset, at which point the label will become âLondon Cycle Network 0â. This will be especially helpful for network=* and cycle_network=* values that are abbreviated, and for mappers who donât speak English.
So does iD, of course, but the catch is that selecting a relation is mutually exclusive of selecting any of its members. iD doesnât use a modal window to manage relations. This has the downside of limiting your ability to poke around before âcommittingâ to a change in relation membership. On the other hand, other workflows become possible, like copying tags from a node to a relation through multiple selection, or visually inspecting a relation on a zoomed-out map. These are the things I missed whenever I would switch back to Potlatch 1 or 2 for some small task, but I donât know if Potlatch 3 has improved in these areas.
If youâll excuse one more workaround: if you can get ahold of a standalone instance of iD that isnât running inside an iframe on the main website, you can use your browserâs Back and Forward buttons to navigate through the selection history.
Am I mapping wrong? I count myself as a power user of iD, but I rarely need to see a relation ID in the UI, even when Iâm mapping route relations or, worse, chronology relations. Iâll grant that relation IDs can be useful if youâre fixing up a tangled mess of relations and donât want to lose your focus, but thereâs already work towards more direct support for that workflow.
Regrettably, Iâve given in and switched to JOSM for boundary mapping in OHM, mostly to fix boundary breakage by other JOSM users. Even JOSM struggles mightily to handle boundary ways that routinely belong to thousands of relations, challenging the field of graph theory. Whenever you feel like taking it out on iDâs customer support team, remember that the historical boundary mappers have it so bad that they fantasize about destroying the evidence.
button to remove members. But maybe line-wrapping the labels would be a better tradeoff.