[postgis-users] union operation
lr at pcorp.us
Fri Aug 7 12:29:18 PDT 2009
At first blush GEOS 3.2SVN seems to handle these rounding issues better
than GEOS 3.1 in the cases where a geometry is valid. Haven't done that
thorough of a test though but sampling I tried that failed on 3.1 worked on
3.2. We'll be releasing binaries for windows (with PostGIS 1.5SVN and GEOS
3.2SVN) sometime this weekend.
If you are on windows and wanted to try GEOS 3.2 SVN even if you are running
1.4/1.3, you would just need to replace the geos dlls in your 1.4/1.3
install. Keep in mind that GEOS 3.2 has not been released yet though the
more testers the better.
Paul -- is there a reason why GEOS 3.2 registers without an SVN. I guess
I'm just being nit-picky cause I can't tell if its production grade or not
by its stamping in postgis_full_version().
Hope that helps,
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Kevin
Sent: Friday, August 07, 2009 11:39 AM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] union operation
lighthousej at gmail.com wrote:
> The geometries themselves look okay, they specify polygons that have
> some area.
Unfortunately, computing area is not indicative of valid geometries. For
example, consider this polygon that has a hole that extends outside of the
polygon, but still returns an area ... whatever that might mean.
SELECT ST_IsValid(geom), ST_Area(geom)
(1 1, 1 4, 4 4, 4 1, 1 1),
(2 2, 5 6, 6 6, 6 5, 2 2)
)'::geometry AS geom
) AS foo;
NOTICE: Self-intersection at or near point 4 3.5
st_isvalid | st_area
f | 5
> Any more things to look at would be much appreciated.
As Regina eluded to, if you've ruled out geometry validity as the problem,
it may be st_union is running into precision issues. Try putting your
geometries through ST_SnapToGrid()
postgis-users mailing list
postgis-users at postgis.refractions.net
More information about the postgis-users