Thanks for the explanation. Il Mar 24 Dic 2024, 18:32 Martin Davis <mtncl...@gmail.com> ha scritto:
> The behaviour of ST_Union with polygons follows the mathematical concept > of union in point-set topology. It produces as few polygons as possible > which contain all the points of the input polygons. > > For LineStrings, they obviously can't "fork", so they are cut at > intersections. And actually ST_Union goes a bit further and cuts the > linework at every node point. This was a design decision from way back. > It avoids the cost of merging contiguous lines (which can be done post > facto with ST_LineMerge). > > What you want is often called "overlay". Currently the best way to do it > is via the technique described in Paul's blog post, or via PostGIS Topology > (which might be more scalable but slower). > > On Mon, Dec 23, 2024 at 9:56 AM Regina Obe <l...@pcorp.us> wrote: > >> Are you unioning one geometry or many? >> >> >> >> The only reason I can think of why ST_Union would return unchanged >> overlapping polygons is if you fed it a geometry collection or invalid >> multipolygon with overlapping polygons. >> >> >> >> In these cases you should be using ST_UnaryUnion >> https://postgis.net/docs/ST_UnaryUnion.html >> >> >> >> >> >> >> >> *From:* Antonio Valanzano <anval...@gmail.com> >> *Sent:* Monday, December 23, 2024 3:47 AM >> *To:* postgis-users@lists.osgeo.org >> *Subject:* ST_Union behaviour >> >> >> >> Does someone know why ST_Union behaves differently with linestrings and >> polygons? >> >> >> >> If a table contains linestrings that overlap at some points then ST_Union >> creates a collection of linestrings that are splitted at intersections. >> >> >> >> If a table contains polygons with overlaps then ST_Union creates a >> collection of polygons that are still overlapped and are not splitted (the >> result contains only the original polygons). >> >> >> >> Thanks in advance. >> >> >> >> Antonio >> >> >> >> >> >
