Splitting an area appears to be broken

[iandees]

The Walgreen's chunk of the building below was torn down late last week, so I'm trying to split it in an attempt to keep the older, northern part of the building in tact in OSM:

When I click the node immediately under Hunan Spring and use the Split operation, that node becomes gray as expected, but so does another node on the other, far west side of the area:

When I click on the node I just split, use the Disconnect operation, and drag one of the nodes out of the way, it looks like iD thinks the two ways are still related because it's drawing an area fill between the old and new ways:

[jfirebaugh]

What is the behavior you expected?

[iandees]

I was shooting for the ability to split the area into two different areas. In JOSM I do this by:

splitting the closed way in two spots:

unjoining the ways I just split and then merging the nodes back together, creating two closed ways.

This is all a convoluted way of splitting an area. Maybe show a "split area" operation when the user closes off an area into two areas like this:

[iandees]

(At the very least, it's a bug that when splitting a closed way in iD two nodes get the split -- the one you had selected and some other seemingly random node.)

[jfirebaugh]

So, you're asking for multiselect support for the split and unjoin operations, or some sort of dedicated "split area" operation. The former seems generally useful and adds little UI complexity, so I think we should add it. I'm not convinced about the latter, especially since your original use case was "delete part of an area" -- is there a way we can make that more direct?

At the very least, it's a bug that when splitting a closed way in iD two nodes get the split -- the one you had selected and some other seemingly random node.

It's actually by design. We don't show the shared node of a closed way, so iD has to choose some other node to split at in order to form a two-way multipolygon. It chooses the opposite node, i.e. preferring to make two ways with an equal number of nodes (+/- 1 node). It could choose the shared start/end node as the second split point, but then it would have to disallow splitting at that node, or choose another node in that case anyway. I chose consistency. (JOSM's solution is to force users to choose two points, interrupting with a modal error dialog if they don't, which seems clumsy to me.)

[iandees]

So, you're asking for multiselect support for the split and unjoin operations, or some sort of dedicated "split area" operation

I suppose so. I agree that a dedicated Area Split operation is complicated and would rather see multi-select be required when splitting a closed way.

In my example above I was trying to save the bottom part of the building because it's still there. There's still a Video Adventure rental store (a Blockbuster/Netflix murder/suicide victim) occupying the building. I guess I could have just deleted the nodes until the northern part of the building was all that's left but that would have been too easy.

iD has to choose some other node to split at in order to form a two-way multipolygon. It chooses the opposite node

This seems very unintuitive to me. My view is definitely tainted by JOSM, but I would rather see it refuse to split on a closed way than pick an arbitrary node as the second split point.

[mikelmaron]

I'm trying to accomplish the same. The split worked for me; though it was unintuitive, had to go into line edit mode to do it. Problem is, the two resulting ways did not inherit tags from the parent way.

[HolgerJeromin]

Often i have a osm building which combines two buildings in reality. I have not found a way to make two ways out of those to retag one half. Splitting the area on one point makes a Multipolygon which is not easy to rebuild back to a way. JOSM has this function in a plugin: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/utilsplugin2#Split_area_.28Alt.2BX.29

[slhh]

Suggested user workflow for splitting of areas:

• Draw a line connecting to 2 nodes of an area (an existing line might be used instead)
• Select the line and the area
• Choose the split tool (scissors)

iD should split the area up along the line. Both resulting closed way areas get the tags from the original area. If the line doesn't have any tag and isn't member of any relation, the line should be deleted (assuming it was drawn for the split).

[1ec5]

My shameless workflow for splitting an area:

1. Rename the primary key, e.g. building=yes to Xbuilding=yes, so iD stops detecting it as an area.
2. Split the way. (iD usually chooses a convenient node to split on the other end.) Unglue the new ways and close them back up, combining ways as needed.
3. Change the tag back to building=yes.

[slhh]

A reasonable area split based on one selected vertex would be: Put the user in line drawing mode with the selected vertex being the start and the rest of the area outline being the finishing target. The line needs to be self intersection protected and the outside of the area needs to be nope classed. This results in a line splitting the area into two parts.

The current area split might be reworked into a more reasonable split based on a two vertex selection, or might be discarded in total.

@bhousel I will try to make a pull request if you agree.

[bhousel]

A reasonable area split based on one selected vertex would be: Put the user in line drawing mode with the selected vertex being the start and the rest of the area outline being the finishing target. The line needs to be self intersection protected and the outside of the area needs to be nope classed. This results in a line splitting the area into two parts.

Can we just make it a new operation that's available if a user has selected both an area and a line that divides it? Then you don't need to worry about putting the user in drawing mode and dealing with whatever stuff might happen in there.

We can do this without turf.js but it might be worth looking at https://github.com/Turfjs/turf/issues/580 for some related work over in that library.

Also, I know it gets real tricky with multipolygons, so I'm not sure how strict you want to make this. An initial version could, for example, just disallow cutting across holes/inners.

[MRVDH]

This ticket has been open for over 5 years. Is anyone working on a solution for this? I haven't really seen any updates. It's a feature that I need a lot. :)

[bhousel]

This ticket has been open for over 5 years. Is anyone working on a solution for this? I haven't really seen any updates. It's a feature that I need a lot. :)

Nobody is working on it as far as I know..

You'll find that that most interesting and impactful tickets are the ones that have been open the longest! Anything else, we would just close or trivially implement.

[BjornRasmussen]

This would be very useful for landcover and water features. For example, I once tried cleaning up the the mess of landcover in New Jersey, but found it much to difficult. This operation would be the magical solution to doing that without JOSM. Here is an image of what I am talking about:

• Select both the area (closed way or multipolygon) and a way that traverses it.
• Press X
• Get this result:

[slhh]

@BjornRasmussen Such an operation would nice, and I was already thinking about making a pull request last year, but I found too many problems:

1. Multipolygons and closed way areas look very similar in iD, so the user should not need to care about the difference in view of splitting, but supporting multipolygons makes most of the problems.
2. Multipolygons are often loaded incompletely, but the split operation needs geometric calculations, which requires all direct and indirect members to be available.
3. iD has the concept of disabling operations in advance instead of generating warnings. Either we need to perform expensive geometry checks in advance, which needs all direct and indirect members to be already downloaded at the time of the availablily check, which is even harder than the previous point. Or we need an operation which can always be enabled.
4. Multipolygons can have multiple outer rings. What is the result of splitting such a multipolygon along a finite line? In case we want to disable the operations in such cases, we need the expensive checks of point 3.
5. The line might intersect the multipolygon multiple times. What is the result of splitting along such a line? In case we want to disable the operations in such cases, we need the expensive checks of point 3.
6. Splitting e.g large landuse multipolygons to get rid of their complexity is an important usecase, and the operation should not be disabled in this case.
7. Such large multipolygons can already be broken, and fixing them directly is potentially too hard. The user should be able to split even such broken ones, to reduce their complexity. Supporting broken ones does likely mean that we can't use a polygon split algorithm of a standard library.

[jidanni]

My shameless workflow for splitting an area

Another workaround is CTRL+C CTRL+V to get a copy of the area, and then place the new one on top of the old one (steady hand). And delete the now extraneous nodes in each. Not too painful if there are only a handful of nodes to delete.

[danieldegroot2]

This issue has since been partially or fully superseeded by #9334.

cc: @tyrasd