On 05/25/2012 08:30 PM, Sandro Santilli wrote:
On Fri, May 25, 2012 at 08:21:25PM +1000, Luca Morandini wrote:
On 05/25/2012 07:26 PM, Sandro Santilli wrote:
On Fri, May 25, 2012 at 01:52:45PM +1000, Luca Morandini wrote:
after seeing some polygons disappear during the generalization
process, I found out that ST_Union and ST_Collect are different
beasts when dealing with intersecting lines.
Yes, ST_Collect simply puts things togheter. ST_Union computes the
point set union. Isn't the manual page clear about that ?
That is clear, what I did not suspect was the different behaviour
when there are "loops" in the collection of lines given as
argument... well, it may be ST_BuildArea that has a different
behaviour when the argument is a collection of linestrings or a
single geometry.
BuildArea is not an aggregate so won't "internally" collect the inputs.
Of course, but it has a different behaviour when it is given a collection of lines
(some intersecting) or a single geometry... on the other hand, it may be ST_Union
that resolves the "loops" before sending the geometry to ST_BuildArea).
I'm not sure this solves your problem.
The issue has been solved by using ST_Union, but I still can't fathom why entire
polygons were dropped by ST_BuildArea when their boundaries intersected..
Regards,
Luca Morandini
Data Architect - AURIN project
Department of Computing and Information Systems
University of Melbourne
_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
