Explode vs Dissolve in GIS

Explode and Dissolve change vector feature structure in opposite directions, but they are not exact inverses. Exploding a multipart feature separates its geometric parts into individual features. Dissolving combines features according to a grouping rule and merges their geometry, often producing multipart features when the resulting parts are disconnected.

Suppose one record represents an island region made of three separate polygons. Exploding it can create three records, one for each island. If those three features retain a common region identifier, dissolving them by that identifier can combine them again into one regional feature.

The important difference is what happens to feature identity and attributes. Explode starts with one feature and creates several. Dissolve starts with several features and decides which of them should represent one output feature.

Explode and Dissolve at a glance

• Column 1: General direction; Explode: One multipart feature → several features; Dissolve: Several features → fewer grouped features

• Column 1: Primary purpose; Explode: Separate geometric parts; Dissolve: Combine features that belong together

• Column 1: Typical effect on feature count; Explode: Increases; Dissolve: Decreases or stays the same

• Column 1: Uses a grouping attribute?; Explode: Usually no; Dissolve: Often

• Column 1: Can duplicate attributes across outputs?; Explode: Yes; Dissolve: Attributes require consolidation or selection

• Column 1: Can create multipart geometry?; Explode: No—the purpose is usually to separate it; Dissolve: Yes

• Column 1: Can remove boundaries between touching polygons?; Explode: No; Dissolve: Yes

• Column 1: Typical question; Explode: I need each disconnected part as its own feature; Dissolve: These features should represent one larger unit

The word explode is not completely standardised across GIS software. In this article it means separating a multipart geometry into its component singlepart features—an operation that QGIS calls Multipart to singleparts and PostGIS can perform using ST_Dump.

Some applications also use explode for other operations, such as splitting a line into individual segments. Always check what a particular tool actually separates.

First, what is a multipart feature?

A vector feature is a record with geometry and attributes.

That geometry does not have to be one continuous shape.

Imagine a region containing three islands:

      _____

                   ______
                  /      \
                 /        \

      ___
     /   \

All three polygons might belong to one record:

• region_id: R01; name: Island Region; geometry: MultiPolygon with 3 parts

This is a multipart feature.

There is one feature and one attribute-table row, but its geometry contains three disconnected polygon parts.

The same principle exists for points and lines:

• a MultiPoint can contain several points;

• a MultiLineString can contain several line components;

• a MultiPolygon can contain several polygon components.

This distinction between number of features and number of geometric parts is essential for understanding Explode.

Explode turns parts into features

Exploding the previous region changes its structure from:

1 feature
3 polygon parts

to:

3 features
1 polygon part each

Conceptually:

• Feature: 1; Region: Island Region; Geometry: Island A

• Feature: 2; Region: Island Region; Geometry: Island B

• Feature: 3; Region: Island Region; Geometry: Island C

The geographic coverage has not necessarily changed.

The three islands still occupy the same locations. What changed is the relationship between geometry and records.

QGIS's Multipart to singleparts operation explicitly performs this transformation: multipart input features are divided into separate singlepart features while their attributes are carried to the resulting records.

PostGIS's ST_Dump expresses the same structure at the database level by returning the individual components of multi-geometries or geometry collections as separate rows.

Explode usually duplicates the source attributes

Suppose the original multipart feature contains:

• region_id: R01; region_name: Island Region; population: 120,000

After exploding three polygon parts, a typical output may look like:

• region_id: R01; region_name: Island Region; population: 120,000

• region_id: R01; region_name: Island Region; population: 120,000

• region_id: R01; region_name: Island Region; population: 120,000

This does not mean each island has a population of 120,000.

The original attribute described the entire multipart region. The explode operation copied that record information to the resulting parts because it does not know how the value should be divided.

This is an important analytical consequence.

If you now sum the population field, you obtain:

360,000

even though the source feature said 120,000.

The geometry operation was successful. The interpretation of the duplicated attribute is not.

Attributes do not automatically become part-level data

This issue applies to many fields.

An original multipart feature might contain:

total_population = 120000
total_area_reported = 800 km²
region_name = Island Region
region_code = R01

After exploding, some attributes remain perfectly meaningful for every part:

region_name
region_code

They describe membership.

Others do not:

total_population
total_area_reported

They describe the original whole.

Exploding geometry cannot infer how population should be distributed between islands.

That would require another data source or a defensible allocation method.

So after exploding, ask of each attribute:

Does this describe the original feature as a whole, or does it genuinely describe every individual part?

The distinction matters before performing statistics on the exploded dataset.

Feature identifiers also need attention

One feature becoming several creates an obvious identification problem.

Suppose the source contains:

feature_id = 27

After exploding into four features, should all four still have ID 27?

If 27 identifies their common parent, retaining it can be useful.

But if the field is supposed to be a unique identifier for each output feature, it can no longer serve that purpose.

GIS software may regenerate internal feature IDs during this operation. QGIS, for example, warns that Multipart to singleparts drops existing internal primary key/FID values and generates new ones in the output.

A robust workflow may therefore preserve:

• a parent ID identifying the original multipart feature;

• a new part ID uniquely identifying each exploded output.

Conceptually:

• parent_id: R01; part_id: R01-1

• parent_id: R01; part_id: R01-2

• parent_id: R01; part_id: R01-3

That structure makes later regrouping much safer.

Dissolve moves in the other direction

Dissolve begins with several features and groups those that should represent one output feature.

Suppose the exploded islands contain:

• part_id: R01-1; region_id: R01

• part_id: R01-2; region_id: R01

• part_id: R01-3; region_id: R01

• part_id: R02-1; region_id: R02

Dissolving by region_id can create:

R01 → one feature containing its three islands
R02 → one feature containing its geometry

As explained in What Does Dissolve Do in GIS?, Dissolve combines geometry within each group and removes boundaries between touching or overlapping polygon features where appropriate.

If members of a group are disconnected, the resulting geometry can be multipart.

QGIS's Dissolve operation follows this model: features sharing selected attribute values can be replaced by a combined feature, and disconnected components can be stored as parts of the same multipart output.

Explode and Dissolve can look like opposites

Consider:

MULTIPOLYGON A
       ↓
    Explode
       ↓
Polygon A1
Polygon A2
Polygon A3

Then:

Polygon A1
Polygon A2
Polygon A3
       ↓
Dissolve by parent_id
       ↓
MULTIPOLYGON A

Structurally, this looks reversible.

And when the geometry parts are disconnected and the grouping field has been preserved correctly, the resulting spatial coverage can indeed resemble the original multipart feature.

But the workflow is not guaranteed to reproduce the original dataset exactly.

Why they are not exact inverses

An exact inverse would restore everything that existed before the first operation.

Dissolve cannot necessarily do that after Explode.

Several pieces of information may have changed.

Original feature identifiers may be gone

The software may generate new feature IDs.

Unless you preserved a parent identifier, there may be no reliable record of which parts originally belonged together.

Attributes may have been modified

A field copied to each exploded part might subsequently be edited.

When those records are dissolved again, there may no longer be one obvious value for the output feature.

Geometry may have changed

If any part was edited between Explode and Dissolve, the reconstructed coverage is no longer the original geometry.

Ordering and internal representation can change

Even when the geographic coverage is equivalent, the exact ordering of geometry components or coordinate representation may differ.

Dissolve can remove boundaries

If the exploded or input features touch or overlap, Dissolve can geometrically merge them rather than simply putting unchanged parts back into a multipart container.

That last distinction is especially important.

Dissolve does more than collect parts

Suppose two polygon features touch:

+------+------+
|  A   |  B   |
+------+------+

If they are dissolved into the same group, their shared boundary can disappear:

+-------------+
|    A + B    |
+-------------+

This changes the geometric structure.

By contrast, simply collecting A and B into a multipart geometry can retain them as two polygon components with their original shapes.

QGIS explicitly distinguishes Collect geometries from Dissolve: Collect groups geometry into multipart features without dissolving overlaps or modifying the individual parts, whereas Dissolve merges geometry.

This gives us three related but distinct operations:

Explode separate multipart components into features.

Collect put several geometries into one multipart feature without necessarily merging their shapes.

Dissolve group features and geometrically merge their coverage.

That is why Dissolve is only approximately the opposite of Explode.

An island example shows where the difference disappears

If three island polygons are completely disconnected:

A          B          C

then collecting them and dissolving them may produce geometries that look effectively identical:

MultiPolygon(A, B, C)

There are no overlaps or shared boundaries to remove.

In that particular case, Dissolve behaves much like a grouping operation.

Now suppose A and B touch:

A|B          C

A geometric Dissolve can remove the A/B boundary.

A simple multipart collection can retain two components.

The difference becomes visible because the geometry interacts.

Explode is useful when parts need independent identities

Why separate a multipart feature at all?

Often because the parts need to become independent analytical units.

Suppose a country feature contains mainland territory and several islands.

You might want to:

• calculate area for each disconnected land mass;

• select individual islands;

• assign part-specific attributes;

• remove one component;

• rank components by size;

• run processing independently on each part.

Those tasks are awkward if all parts live inside one feature.

Exploding provides one record per geometric component.

The resulting parts can then be treated independently.

Explode can help reveal hidden multipart structure

Multipart geometry is not always visually obvious.

A feature may look like one ordinary polygon until you discover a tiny disconnected part many kilometres away.

Exploding it can make those components easier to inspect because each becomes its own feature.

This can help answer questions such as:

How many disconnected components does each feature contain?

Are there unexpectedly small polygon parts?

Does one administrative feature contain distant fragments?

Which part accounts for most of the feature's area?

The operation can therefore be useful for structural inspection as well as for preparing later processing.

But a disconnected part should not automatically be deleted merely because exploding made it easier to notice.

It may represent legitimate geography.

Dissolve is useful when parts should share one identity

Dissolve addresses the opposite modelling problem.

Suppose a dataset contains hundreds of district polygons but the analysis should work at regional level.

The district boundaries no longer define the desired units.

Dissolving by region creates features whose identities align with the analysis.

Similarly, after exploding an island region for part-level work, you may later need to return to a region-level representation.

If every exploded component still has the correct parent region code, Dissolve can rebuild that higher-level grouping.

The operation is therefore not simply about making geometry bigger. It is about deciding which records represent one geographic entity.

Do not dissolve by a field merely because it is repeated

Suppose exploded features all contain:

country = Cameroon

Dissolving by country would group every part belonging to Cameroon.

That may be appropriate if the intended output is one national feature.

It would be inappropriate if the desired output is one feature per municipality.

A repeated field value is only a valid dissolve key when its category matches the geographic unit you want to create.

The same warning applies after Explode.

The fact that every part inherited an attribute does not mean that attribute should determine regrouping.

Explode does not divide quantitative values

Consider a MultiPolygon representing three agricultural areas with:

production_tonnes = 400

Exploding it into three polygon features does not establish how those 400 tonnes are distributed.

You might get:

Part A → 400
Part B → 400
Part C → 400

because the attribute is copied.

Those are not three independent production measurements.

To assign values such as:

Part A → 200
Part B → 130
Part C → 70

you need a defensible disaggregation method or source data at the part level.

Geometry Explode is therefore not statistical disaggregation.

This distinction becomes important in workflows involving counts, population, revenue, emissions, production, or any other additive quantity.

Dissolve does not automatically aggregate attributes correctly either

The reverse problem exists during Dissolve.

Suppose the three parts genuinely have:

• Part: A; Population: 20,000

• Part: B; Population: 30,000

• Part: C; Population: 10,000

Dissolving them into one feature does not inherently tell the GIS to calculate:

60,000

Some workflows allow explicit aggregation. Others may retain a value from one source record or otherwise handle attributes according to tool-specific rules.

QGIS's standard Dissolve currently retains input fields but takes output values from the first input feature processed rather than automatically calculating statistics.

If the output feature needs total population, use an appropriate aggregation rule rather than assuming geometry combination performed the statistical calculation.

Exploding polygon holes is a different question

A polygon's hole is not the same thing as another polygon part.

Consider:

+-------------------+
|                   |
|      +------+     |
|      | hole |     |
|      +------+     |
|                   |
+-------------------+

This is one polygon with an interior ring.

A standard multipart-to-singlepart operation does not normally turn that hole into an independent polygon feature. The hole is part of the topology of the surrounding polygon.

By contrast:

Polygon A       Polygon B

stored together in one MultiPolygon are separate polygon components and can be exploded.

So if your goal is to extract polygon rings, holes, or boundaries, a different geometry operation is needed.

Not every visually separate shape inside a geometry is a multipart component.

“Explode lines” can mean something else

The terminology deserves another warning.

QGIS has an operation literally called Explode lines.

It does not mean Multipart to singleparts.

Instead, QGIS Explode lines replaces each input line with individual line segments connecting consecutive vertices.

A line such as:

A •────•────•────• B

can become three separate segment features:

•────•

     •────•

          •────•

That is a different transformation from separating the components of a MultiLineString.

This is why workflow documentation should state what explode means rather than relying on the word alone.

In the context of Explode vs Dissolve, the useful comparison is multipart-to-singlepart exploding.

Feature count is a useful diagnostic, but not a definition

Explode often increases feature count.

Suppose:

100 input features

contain a total of 146 geometric parts.

After exploding, you might get:

146 output features

Dissolve usually moves in the opposite direction.

Suppose those 146 features contain 20 unique region codes.

Dissolving by region may produce:

20 output features

This makes feature count a useful check.

But it is not the definition of either operation.

A layer containing only singlepart features may have the same feature count after Explode because there was nothing to separate.

Likewise, dissolving by a field whose value is unique for every input record may leave the feature count unchanged.

The operations are defined by what they do to feature structure—not by guaranteeing a particular count.

Disconnected output does not imply failed Dissolve

Suppose you dissolve several municipalities belonging to one province.

The province includes mainland territory plus two islands.

The result may be one feature with three disconnected polygon parts.

That is a perfectly normal MultiPolygon.

A user expecting “Dissolve means one polygon” may think the operation failed because three shapes remain visible.

But Dissolve creates one feature per group, not necessarily one continuous piece of land.

This distinction is exactly why multipart geometry exists.

What Does Dissolve Do in GIS? covers that behaviour more fully.

Explode can be useful before calculating part-level geometry statistics

Suppose a MultiPolygon contains five disconnected polygons.

Calculating area on the multipart feature gives the combined area of all five parts.

If you instead need:

• area of each island;

• perimeter of each component;

• centroid of each component;

• largest component;

• smallest component;

exploding first can make those calculations straightforward because each part becomes its own feature.

The important qualification is that these are geometry-derived values.

They can legitimately be recalculated from each new component.

That differs from copying a non-geometric attribute such as total population and pretending it became part-specific merely because the feature was exploded.

Explode and Dissolve change the unit of analysis

This is the deeper connection between the two operations.

Before Explode:

one row might represent a region.

After Explode:

one row might represent a disconnected geographic component of that region.

Before Dissolve:

one row might represent a district.

After Dissolve:

one row might represent a region.

The geometry changes, but so does the unit represented by a database record.

That affects:

• counting;

• summarisation;

• identifiers;

• joins;

• selections;

• statistics;

• later overlays.

A workflow should therefore decide what a feature is supposed to represent rather than treating Explode and Dissolve as purely geometric housekeeping.

Which should you use?

Use Explode when the problem sounds like:

“This one feature contains several geometric parts, and I need to work with those parts independently.”

Examples include:

• analysing individual islands within a MultiPolygon;

• separating disconnected pieces before calculating geometry statistics;

• assigning attributes to individual components;

• inspecting unexpectedly multipart features.

Use Dissolve when the problem sounds like:

“These separate features should represent one geographic unit.”

Examples include:

• districts becoming regions;

• parcels grouped by a common category;

• overlapping buffer zones becoming one coverage area;

• previously exploded parts being regrouped by a preserved parent identifier.

And if the question is only:

“Put these geometries into one multipart feature without merging their overlapping or touching shapes”

then a Collect operation may be closer to what you mean than Dissolve.

A practical decision table

• Question: Does one feature contain several parts I need separately?; Explode: ✓; Dissolve:

• Question: Do I need one record per disconnected component?; Explode: ✓; Dissolve:

• Question: Do several features need to become one logical unit?; Explode: ; Dissolve: ✓

• Question: Should common boundaries between grouped polygons disappear?; Explode: ; Dissolve: ✓

• Question: Do I need to preserve a parent-child relationship?; Explode: Preserve parent ID; Dissolve: Use that grouping ID

• Question: Will attributes automatically become part-level values?; Explode: No; Dissolve:

• Question: Will numeric attributes automatically aggregate correctly?; Explode: ; Dissolve: No

• Question: Can the output be multipart?; Explode: Normally no; Dissolve: ✓

• Question: Do I only want to collect parts without geometrically merging them?; Explode: ; Dissolve: Use Collect instead

If you expect to dissolve later, preserve the parent identity

A useful production practice is to preserve the original grouping information before exploding.

Suppose the source feature has:

region_id = R01

After exploding, retain that field and create a unique part identifier:

R01-1
R01-2
R01-3

Now the relationship is explicit:

R01
├── R01-1
├── R01-2
└── R01-3

Later, dissolving by region_id can reliably reconstruct the region grouping.

Without that parent key, trying to infer which components originally belonged together from spatial proximity or attribute similarity can be much less reliable.

This illustrates a broader GIS principle: geometry operations should preserve enough lineage to explain where derived features came from.

The difference comes down to what one row should mean

Explode and Dissolve can look like simple opposites:

one becomes many; many become one.

That is useful as a first approximation, but the real distinction is more important.

Explode asks:

Should the geometric parts of this feature become independently addressable features?

Dissolve asks:

Should these separate features be treated as members of one geographic group?

Those questions are about feature identity as much as geometry.

Exploding may copy an original feature's attributes without making them valid part-level measurements. Dissolving may combine geometry without automatically producing meaningful aggregated attributes. And dissolving exploded parts does not necessarily recreate the exact original dataset unless the original grouping and semantics have been preserved.

So before choosing either operation, decide what one output row is supposed to represent.

Once that is clear, whether the geometry should be split or combined usually follows naturally.

References

1. QGIS Documentation — Multipart to singleparts. Documents the separation of multipart input features into individual singlepart features, with source attributes carried to the resulting records.

2. QGIS Documentation — Dissolve. Documents grouping features by attributes or across a whole layer, geometric merging of dissolved features, multipart output, treatment of disjoint parts, and current attribute behaviour.

3. PostGIS — ST_Dump. Defines the expansion of multi-geometries and geometry collections into their constituent components, providing a database-level equivalent of the multipart-to-singlepart concept.