Multipolygons are dissolved on merge

[m-kuhn]

When having multiple multipolygons and merging these, each multipolygon is dissolved. Dissolving only happens "within" source polygons, but not across polygons.

What I would expect to happen is that each individual polygon is preserved in multipolygons.

[uclaros]

If the source multipolygons don't intersect (but their parts do intersect within each source), then no dissolve takes place and all parts become parts of a bigger multipolygon. (expected) If the source multipolygons intersect then a total dissolve takes place. (not expected, only touching parts should dissolve) In the above screencast the source polygons probably do not share the common edge, rather they probably only intersect on one or more points so it looks like dissolve across polygons has not taken place.

[m-kuhn]

What I would like to do here is preserving all original parts. It's a block of solar panels which should stay individual parts but share the attributes. So no dissolve should take place. This operation is currently impossible with QGIS.

Dissolve makes sense (== is the only way for merging) for single polygons. But for multipolygons I'd prefer to have a separate dedicated operation "convert to single" "dissolve" or similar as a followup step to control the process.

[gioman]

This operation is currently impossible with QGIS.

@m-kuhn you want to use the tool "merge attributes of selected features", this way you will merge the attributes but not the geometries.

[m-kuhn]

Let me check

[m-kuhn]

No, also does not look like what I've been looking for. We still have two features. I need one resulting feature with all parts merged, but not dissolved.

[uclaros]

This is definitely a bug, only the touching parts of different source features should be dissolved. To get your job done until this is fixed you can either use collect geometries, (this however will create a new layer) or keep your source features in a distance, like in the beginning of your screencast, use merge (no dissolve takes place since separate features do not touch) an then move the one feature using the vertex tool by selecting all its vertices.

[m-kuhn]

Thanks for the suggestions, the workflow here is to quickly add additional panels (parts) by copying/move existing ones. I just tried them, but with no success. Collect geometry fails because of "invalid geometries". "Fixing geometries" just removes some panels to make sure no shared edges exist. Keeping source features in a distance is not possible. The parts are adjacent on purpose.

This is definitely a bug, only the touching parts of different source features should be dissolved.

I'd say not even these. I'd say it should keep all parts and leave it to the user to dissolve with separate tools.

[gioman]

I'd say not even these. I'd say it should keep all parts and leave it to the user to dissolve with separate tools.

@m-kuhn seems you need a new interactive digitizing tool :)

[m-kuhn]

Possibly. Do you think adjusting the current one for predictable behavior with multipolygons is a bad idea?

[gioman]

Do you think adjusting the current one for predictable behavior with multipolygons is a bad idea?

@m-kuhn bi, but I also think you cannot force to another different behavior compared to the actual one, as this may be very well what some users expect/want. So it must be optional.

[uclaros]

Your invalid geometries are most probably because of part intersection within multipart features, shared edges are ok. Also, by keeping a distance, I mean between multipart features, not between their parts. Here's a quick demo of how I'd do it using those two methods:

I'd say not even these. I'd say it should keep all parts and leave it to the user to dissolve with separate tools.

So far the merge tool is a geometry dissolve tool with interactive field selector: If features A and B overlap/share edges, then a single feature is created and the user picks how field values are inherited. If features A and B are disjoint, then a multipart feature is created and the user picks how field values are inherited. Apart from the field inheritance part, this is exactly how the dissolve processing tool works. If we did not dissolve overlapping parts, then the resulting geometry would be invalid (self intersecting multipart).

My suggestion would be:

• Make merge work with multiparts similarly (dissolve overlapping parts, don't dissolve parts within same geometry)
• Make collect geometries work with edit selected features. Collect is the opposite of multipart to singlepart.
• Add an option to add part tool (by right clicking?) to add part from clipboard.

[m-kuhn]

Interesting. I got it to work the way you proposed with the first round (creating a single polygon, copy, snap, collect) but then duplicating this and snapping and collecting it was again complaining about invalid geometries. It seems it work under some laboratory conditions, but not really in a way you could give it to a client with good confidence that it will work for him in daily life.

Make merge work with multiparts similarly (dissolve overlapping parts, don't dissolve parts within same geometry)

Completely agreed on the second part (don't dissolve parts within same geometry). About the first one, how would you deal with "touches"? Also dissolve? Does it make sense to deal with it differently than overlap?

Make collect geometries work with edit selected features. Collect is the opposite of multipart to singlepart.

With "In place"? Very good idea!

Add an option to add part tool (by right clicking?) to add part from clipboard.

:+1:

[uclaros]

It seems it work under some laboratory conditions, but not really in a way you could give it to a client with good confidence that it will work for him in daily life.

I sadly translate client and daily life to ignore topology and treat QGIS like it uses a precision model

how would you deal with "touches"? Also dissolve?

You cannot produce a valid singlepart by dissolving two polygons that touch on a single point, so touches should produce two distinct parts. Resulting geometry validity should be our aim.

[m-kuhn]

I sadly translate client and daily life to ignore topology and treat QGIS like it uses a precision model

That is probably correct. Or more "my main goal is managing the attributes of those solar panels" than "thinking about geometry precision models and topology"

Resulting geometry validity should be our aim...

... if unambiguously possible. Otherwise as much information as possible should be preserved (even in a temporarily invalid geometry) to let the user consciously decide how to come back to a valid state. Rather than taking a decision for the user about how the desired validity should be achieved.