Right now it is impossible to select between multiple overlapping polygons

[a1668753]

Description: if multiple polygons overlap you can only select one of them. This is missing feature in JOSM too.

Solution is to implement "what is under here?" feature found in some GIS systems. Prompt user to select particular polygon that contains point requested by user.

Bonus points if it will order polygons in reverse layer level, i.e.:

1. house polygon
2. landuse residential
3. district
4. city boundary
5. etc

You may also query not point but circle with small radius (.1 m) - this will be more usable with bad input devices (touch screens, poor mouse pouting).

Please note that this functionality shouldn't replace current "select" function but add new one. Usually GIS systems use left mouse button as "select" and place "what under here" in right click menu.

[pnorman]

Description: if multiple polygons overlap you can only select one of them. This is missing feature in JOSM too.

JOSM uses middle-click for selecting from overlapping objects.

Time permitting, I'll write something about how CAD/CAM software handles this case.

[jfirebaugh]

Polygons are sorted smallest-on-top, so it's almost always possible to select the larger one underneath by clicking where there isn't overlap. If you have a specific situation where this isn't possible I'd like to take a look.

[a1668753]

jfirebaugh, it is not always possible to select between multiple polygons. You can't select between polygons at exact same place (editor mistake).

"what under here" feature differs from "select":

1. it allows you to select without change of viewpoint (zoom in/out, map pan)
2. allows you to inspect buggy parts of maps with multiple polygons at exact same spots

[bhousel]

I've had trouble selecting overlapping ways where someone drew 2 roads or hiking paths on top of each other. But in this case I always just disconnect and move them apart.

[ghost]

Here is demo: http://www.openstreetmap.org/#map=17/54.00345/49.18775

Right now you cannot select (at least easily) island with name=Борок using ID editor.

[pbb72]

I found two workarounds for this problem:

• If the object has a name, use the Search function to find (and automatically select) it.
• Use the OpenStreetMap slippy map to find and highlight the object, and then switch to iD. The object will still be selected.

Not the best workarounds, and it will not help in every case, but hopefully this helps some people that are struggling.

[waldyrious]

Polygons are sorted smallest-on-top, so it's almost always possible to select the larger one underneath by clicking where there isn't overlap. If you have a specific situation where this isn't possible I'd like to take a look.

@jfirebaugh this is the case with tagging of buildings for 3D rendering, as described in https://wiki.openstreetmap.org/wiki/Simple_3D_buildings (emphasis mine):

The building outline is a closed way or multipolygon tagged with building=*. It represents the area of land covered by the union of all parts of the building. The outline is also referred to as the building footprint.
(...)
Cover the whole building outline with building:part=* areas, tagged with their respective height and other attributes.

[verdy-p]

Yes we need to be able to select alternate polygons. This is a frequent problems in iD, notably when these polygons are adjascent or we need to split a polygon in several parts, and still be able to adjust the largest one, not just the new smallest one!

The logic "using the smallest polygon" is simply corrupted, badly thought with a limited vision of what is needed. For this reason, iD users will frequenty break existing polygons by only fixing one, or deleting the nodes of parts still needed by the largest one; they redraw new objects and delete all existing ones, not caring about preserving their tags or necessary nodes with additional tags.

This is a major problem.

[bhousel]

Thanks @verdy-p, I'm planning to add the ability to choose from multiple overlapping features to iDs new menu (#3753). The new menu was just merged over the weekend, and it unblocks a bunch of other usability issues, like this one, that would have been really hard to do with the radial menu.

[verdy-p]

Note also that is there are multiple polygons creating a perfect tiling of the plane, some of them will NEVER be selectable.

Imagine the case of a set of polygons that are squares roughyly the same size and arranged in a regular grid: that logic will never allow us to select each polygon polygon individually, as you may be able to select only the polygons around it (if they all are just a bit smaller than the polygon we need to select). That situation is more frequent for polygons fully surrounded by only 2 or 3 adjascent polygons (e.g. a large water pond adjascent to a narrow forest band and a small field).

[verdy-p]

One idea: allow an action to add ALL touching polygons to the current selection and then allow the user to remove unnecessary objects from the selected list.

Another idea: allow us to preserve lists of objects in a pseudo relation (that won't be saved but preserved in a list of objects in which the user is interested, and saved only in their personal editing profile. Users can then attach to these personal lists a distinctive name that allows them to identify them, without even needing to make them into a real relation. These personal lists of objects could then have a field (similar to the role in a relation) for each member. This would facilitate the editing of real relations as these personal lists are just at hand. Users would purge the lists from their profile they no longer need and that don't fdacilitatge their work. These lists can be used to create personal TODO lists, locally annotated (name of lists, pseudo-roles or description attached to them). This would allow users to manage their work without forgetting things still not done.

These personal lists in this case would also help editing adjascent objects such as those concerned in this bug. For such lists it would be easier to select again several objects to perform actions on the real data (such as merging, or cleaning up remaining fragments after geometric corrections)

One way of creating these lists would be an extension of the clipboard (copying adds a list to the history). Lists should be created with default names, such as "list1", "list2"... or using a timestamp (displayed as 3 seconds ago", "2 hours ago", "yesterday" for the short name, the timestamp of their last creation/modification being shown in details). Users would as well cleanup this historic clipboard themselves in a pane showing their current personal lists of objects.

These personal lists would not be saved at all to the server, only kept in their local session data (in the local database on their browsers) but they could be "refreshed" to cleanup automatically all objects that are no longer in the database, and already part of really edited objects that we want to delete, but whose deletion is still pending a "save".

[verdy-p]

Another simple example:

+--------+--------+
|        |        |
+--------+--------+

This is a single building mapped as a single (outer) closed way, but there are also two separate closed ways subdividing it (for example a shop and a theater): in this example (with the current logic allowing us to select only the smallest area) you cannot select the outer building polygon, only the two subareas (and only one if clicking on any point of the common segment).

This example could as well be a sport center park subdivided into two distinct sport pitches (e.g. tennis and handball), both being enclosed around a fence on the outer edges (and just two nodes on them for gates). Numerous examples like this can be found on real maps (that do not necessarily involve splitting closed ways and merging common ones to create multipolygon relations, notably when the polygons are small with not too complex geometries like boundaries).

[waldyrious]

+--------+--------+
|        |        |
+--------+--------+

in this example (...) you cannot select the outer building polygon, only the two subareas.

Indeed. Note that this is a useful format for modeling many common structures. See for instance this apartment building where each unit has been added as a separate polygon. The workaround I've used to be able to select the wrapping polygon is detaching and moving one of the points, editing the tags on the main polygon, and re-attaching the points -- which is, of course, needlessly convoluted.

[slhh]

The issue would be solved by #3843. Unfortunately, the part of the requested enhancement, which @bhousel has already agreed on, would limit it to the selection of a single or first element.

#3603 ( pull request #3631 ) would also solve the issue, at least in case of closed way polygons. An extension to multipolygons would be possible.

The solution based on #3843 would be the more efficient to use one and the solution based on #3603 would be the easier to discover one. Both #3843 and #3603 do have other benefits than solving this issue here, and make sense to coexist.

[verdy-p]

@slhh: this is still exactly the same case as #3843: consider just one of the two inner subareas and the big outer area: they overlap entirely, and you cannot select the outer one when clickin on their common edges: you need to find another edge and hope that it will not select another adjascent area.

So this example describes fully what is needed overlaps, common edges shared by multiple areas (closed ways). the logic of the smaller area being selectable will fail in extremely frequent cases, for various kinds of features: buildings, natural land cover, usage, linear features such as fences and highways, boundaries, electric lines (modeled as a single way even if there are parallel wires belonging to different routes sharing the same segments and the same power poles...) and so on...

For now the only way to solve this is to split closed ways and create multipolygons where segments joining the same nodes will be merged: this requires many multipolygons, even for small objects.

Note that unmerging shared nodes in order to move one of them (there's no mean to select them) may alter node properties: you'll start moving one of the nodes, or all of them, and way forget to merge them again or if you do it, will not merge them exactly to the previous position: the merged node will be different, and could break cases where their position is normative (known with exact coordinates), notably boundary nodes on international borders): the tip will be useful in cases where moving them slightly has no real importance, but this could be done at low zoom levels where the changed position has a severe impact possibly creating intersections with other nearby objects, such as moving a single node of an highway so that it now partly covers sea without bign a bridge, or partly covering surrounding buildings without any covered passage through it.

[slhh]

@verdy-p
One of the goals of #3843 is to solve the issue which is described here. There are the requested enhancements:

1. Add a shortcut to select the feature which is currently shown in the sidebar. Let's assume it's the spacebar here.
2. Add shortcut keys to cycle through all features at the mouse position. Let's assume it's the tab key here.

With these enhancements you could easily select the large area:

• Enter browse mode (clear selection)
• Position the mouse where the large area would be selectable if there were no overlapping small area.
• The small area would be shown in the inspector and hover styled on the map.
• Press the tab key until the large area is shown in the inspector and hover styled on the map.
• Press the spacebar to select the feature shown in the inspector, which is the large area.

[1ec5]

As long as the overlapping areas and/or lines are connected to each other, Potlatch lets you select one of the areas with this workflow:

1. Select one of the shared nodes.
2. Press / to bring a different way to the front, cycling among the connected ways.
3. Press W to select the parent way of the selected node, or click the way that’s now in the foreground.

In iD, pressing \ cycles among the connected ways for the purpose of navigating among the nodes of a way, just like Potlatch’s / key binding. However, there isn’t an equivalent to Potlatch’s W key binding for selecting the parent way of the selected node. That would be useful for other workflows as well, such as editing streetcar lines that coincide with roadways: #1239.

[1ec5]

Riffing on the idea proposed in #2225 (comment):

One idea: allow an action to add ALL touching polygons to the current selection and then allow the user to remove unnecessary objects from the selected list.

Selecting an edge shared by multiple ways (whether areas or lines) could select all those ways. When there’s a multiple selection in the sidebar, it’s already the case that you can click an ✖️ next to a feature to remove it from the selection or click a feature’s label to select just that feature.

[yaugenka]

In iD, pressing \ cycles among the connected ways for the purpose of navigating among the nodes of a way

How about using the same key for switching between overlapping ways/areas when you have a way selected and it has at least two nodes shared with another way?

[slhh]

How about using the same key for switching between overlapping ways/areas when you have a way selected and it has at least two nodes shared with another way?

In most cases ways or areas are partially overlapping only. Therefore, we need a position to define a fixed set of overlapping features to be cycled through. Unfortunately, using a shortcut key can't provide that information.

[tbertels]

JOSM allows middle clicking and alt + left click. https://wiki.openstreetmap.org/wiki/JOSM/Advanced_editing#Unglueing_and_untangling

How about doing the same thing?

[jidanni]

In iD once two items share the same location, the "buried item" is no longer accessible… an artifact buried in the map.

Yes there are tricks, like grabbing and distorting other people's layers to get at it.
But then one needs to remember to carefully try to put them back where they were when finished.

A beginning editor would sense that he is about to wreck other people's work and figure the cost of accessing the buried item is just too great, and just leave it there.

On OSM.org I can just use the Query Features button or right click, to get a tidy list of links to all that is there (and indeed yes if we then click "Edit" in the upper left we can edit them, but that is not obvious to the user, who assumes the answer must be within iD. Also though we can edit the feature, all editing must be only in the left panel, as any clicking on the feature will immediately select the overlying feature instead. )

[jjmontesl]

Another example, where I don't dare removing the incorrect "construction area" below the supermarket and its parking:

https://www.openstreetmap.org/edit?#map=19/40.95723/-5.67744

(The invalid area is w762437182)

[kymckay]

@jjmontesl A pro-tip workaround for you while this issue is unsolved:

https://www.openstreetmap.org/edit?way=762437182#map=19/40.95723/-5.67744

Open that link and hit the delete key (can also use node and relation for similar cases).

[jidanni]

@jjmontesl A pro-tip workaround...

So the full steps to the workaround would start with first going to OSM.ORG and doing a query features on the spot to obtain the way link...

[jjmontesl]

I guess @SilentSpike meant hitting CTRL-I to get the way ID, and building the URL automatically. Before that, I have to remove enough features to reach the buried one, get the ID, then hit CTRL-Z to undo, build the URL and edit as needed. In order to be able to press DEL, I also had to drag the map before, in case someone is trying to do the same.

Well at least I now have a full workaround. But making SHIFT-CLICK cycle through all features below the mouse cursor wouldn't be a crazy idea either... 8-) or something.

(I suggest you remove the reference to "hit the delete key" from your message, to avoid mistakes... once the node is selected one can delete or edit it as needed).

Cheers!

[jidanni]

But those "w237949253" CTRL+I way ids are only available for features that one can click on, not for buried features, no? I mean if I can't click on it, then CTRL+I won't help me.

[tbertels]

A few pictures are often better than words, so here's a workaround to remove a hidden polygon:

1.

2.

3.

4.

5.

6.

[dead10ck]

Is any progress being made on this? I hate to be that guy that doesn't contribute code and comes in complaining, but this issue was opened 6 years ago, and it's still a major usability issue.

[andreasscherbaum]

Same question here. All the tricks mentioned (like use middle mouse button, or Ctlr, or Right Alt) don't work here.
Chrome, on Linux.

[verdy-p]

The trick I usually do is to add an arbitrary node on the middle of a segment joined by two shared nodes: this would normally add a new node and add it to all the overlapping polygons or polylines. You'll note that this node will also be grey (meaning it would be shared across polygons too).

Then I use the right click on this arbitrary node to separate the polygons (this duplicates it in multiple distinct nodes at the same position), and I can select any one of these nodes to shift them around: this removes the superposition of segments and I can select tthese segments to select the appropriate polygon/polyline they below to. At least now we have separate segments allowing to select the polygon/polyline we're interested in: we can suppress one if we want, and work on them. We just have to remember that there are still copies of the new arbitrary node that were detached.

Once this is done, the new detached nodes that were created temporarily and that remain can be removed: this will restore the state of the polygons/polylines we did not want to alter (such as boundary lines or survey points and "legal" points that we must not move freely).

Note also that when selecting polygons that are joining on the same border but don't overlap, you can select each polygon on each side of the segment by clicking on the semi-transparent colored border inside the polygon, so in that case they can be selected distinctly (this works only for polygons mapping an area; not for polylines without "inner" area.)
Finally I can submit the changes only for the polygons we want to work with. No other random lode will be added

[jidanni]

"Then I use the right click on this arbitrary node to separate the polygons"… Hmmm maybe such right click capabilities should be available on all such nodes, with no need to especially create a new node. Indeed same for when right clicking on such line segments too. So right clicking on an overlapping anything, should give one access to (switching to) any of the layers.

[verdy-p]

The reason why I use this technic is to avoid modifying things that don't need to be modified, but I can't select the other ways or polygons to see their actual geometry if it is correct (and when all nodes emphasized in the selected object are not "white" (not shared by multiple lines/polygons) but "grey": this does not mean that it may eventually be shared by only 2 lines/polygons, and sometimes you could find another hidden polygon with an incorrect shape whose nodes were incorrectly joined, creating anomalies, or they could be remnants of something that should have been deleted, or duplicates, possibly with one with the wrong tags that need to be changed.
Note that in general we should avoid overlapping polygons, and admit only touching polygons; but this happens for some cases (e.g. a landuse containing a building, where the building touches the landuse's border; the typical case is a school area in a city, where the school's building touches a residential building by contact on their wall: you find 4 polygons along this wall, i.e. 2 polygons on each side. Additionally you may have linear features such as barriers (fences, gates, hedges and you's want to detail the kind of borders. You could decide to use a multipolygon relation for defining the areas, but frequently on small objects, this is overkill.
So the simplest solution is still to add an aribtrary node in the middle of existing shared segments and then disjoint the node into as many nodes as there are lines or polygon borders, in order to separate them geometrically. Then you can select each polygon easily, and look at their tags, and work on them, before joining these arbitrary nodes again or removing them. This is even simpler then using CTRL-clik or similar, and this allows using selection of multiple objects (something you can't do with just a system to rotate the current selection if that selection contains more than one geometric objects.).
This technic is not just for iD because I use it as well in JOSM and other online editors or SIG software for custom maps, or for generic vector-drawing tools (e.g. for editing diagrams, or in CAD software). I even remember I used that technic already at end of the 1980's in MacDraw (on good old Apple Mac machines)

[sun-geo]

verdy-p:

The trick I usually do is to add an arbitrary node on the middle ...

Very good explanation and description of the technic I also use for long while (did find out one day by myself).
Because this workaround is little bit time consuming, maybe not doable for the average iD user (so far I understood iD is intentionally made for users which doesn't need to have a deep knowledge of the osm data structure) and a bit error-prone (you have to care to delete the temporary nodes) i also wonder if there could be created any tool or function to get a bit easier access to the properties of different overlapping area objects.

[1ec5]

#2225 (comment):

One idea: allow an action to add ALL touching polygons to the current selection and then allow the user to remove unnecessary objects from the selected list.

#2225 (comment):

In iD, pressing \ cycles among the connected ways for the purpose of navigating among the nodes of a way, just like Potlatch’s / key binding. However, there isn’t an equivalent to Potlatch’s W key binding for selecting the parent way of the selected node. That would be useful for other workflows as well, such as editing streetcar lines that coincide with roadways: #1239.

#8264 implements this approach, adding a keyboard shortcut that selects all the connected lines and areas. You can use the Features list to either select a single way or deselect the other ways.

#2225 (comment):

Selecting an edge shared by multiple ways (whether areas or lines) could select all those ways. When there’s a multiple selection in the sidebar, it’s already the case that you can click an ✖️ next to a feature to remove it from the selection or click a feature’s label to select just that feature.

I ended up putting the multiple selection behavior behind a keyboard shortcut and only if a node is selected. That seems to be less error-prone than performing a multiple selection that the user might not have had any reason to expect.