ST_Collect

What is ST_Collect?

ST_Collect is a PostGIS function that groups multiple input geometries into a single MULTI* geometry or GEOMETRYCOLLECTION. Unlike ST_Union, it performs no merging, intersection, or dissolving of boundaries — the output preserves every input geometry as-is, simply bundled into one container.

1ST_Collect(geometry g1, geometry g2) → geometry
2ST_Collect(geometry[] g_array) → geometry
3ST_Collect(geometry set g_field) → geometry   -- aggregate form

When all inputs share the same geometry type, the result is the corresponding MULTI* type (e.g. all points → MULTIPOINT). Mixed input types return a GEOMETRYCOLLECTION. Much faster than ST_Union because no topological processing is performed.

When would you use ST_Collect?

Use ST_Collect when you need a single geometry value for downstream operations but do not want the cost or side-effects of a true union. Common patterns include aggregating per-group geometries in a GROUP BY (for example, all delivery points per route), passing a batched geometry to ST_ConvexHull or ST_Centroid, or assembling an envelope for spatial filtering with ST_Extent.

1SELECT route_id, ST_Collect(stop_geom) AS stops
2FROM delivery_stops
3GROUP BY route_id;

Because ST_Collect skips the expensive overlay engine, it is also the right choice when you intend to feed results into ST_ConvexHull, ST_ConcaveHull, or ST_Envelope — those operators only care about vertex sets, not topological validity.

FAQs

What is the difference between ST_Collect and ST_Union?

ST_Collect bundles geometries into a multi-geometry without any geometric processing — overlapping polygons remain overlapping, duplicates are kept. ST_Union dissolves shared boundaries and merges overlaps into a single clean geometry. ST_Collect is orders of magnitude faster but produces potentially invalid results if you need a topologically clean union.

Do all input geometries need the same SRID?

Yes. ST_Collect raises an error if inputs have mixed SRIDs. Normalize with ST_Transform before aggregating if your source data spans multiple projections.

What is the return type when inputs are mixed?

If all inputs are the same type (e.g. all POINT), the result is the matching MULTI* type. If inputs differ (e.g. points and linestrings), the result is a GEOMETRYCOLLECTION, which many downstream consumers handle less gracefully — filter by type with ST_CollectionExtract if needed.

Can ST_Collect handle empty input?

The aggregate form returns NULL when the input set is empty. When called with explicit arguments, any NULL input is ignored; if all arguments are NULL the result is NULL. Always wrap in COALESCE if downstream code assumes a non-null geometry.