Mike, I'm not sure if this is related but I was using the same version of geos today but from c++ directly and I was also getting an error when trying to use geos union in a loop where I continually union the previous resulting union geometry to the next in the table. It would always throw an error when parsing a multipolygon wkb saying that one of the linear rings was not closed (which it isn't). When I just union two geoms then all unions work correctly. The ring it complains about is a ring created from a previous union operation and it looks like the geos coordinate sequencer doesn't parse the ring correctly or the ring is failing on creation. I validated my wkb binary and all rings in my table geometries are closed.
I think this is a possible geos problem. I will debug further tomorrow and let you know if I find the error in the geos code and send you the fix if I find one. Best regards, Martin Sent via BlackBerry by AT&T -----Original Message----- From: Mike Leahy <[EMAIL PROTECTED]> Date: Mon, 17 Mar 2008 17:14:31 To:[email protected] Subject: [postgis-users] st_union says geometries have different srids Hello list, I seem to be having trouble with st_union as an aggregate function. Sorry if this is a known issue, but a quick search didn't turn anything up similar. Below is an example where I have two polygons next to each other test=# create table test (gid serial primary key); test=# select addgeometrycolumn('public','test','test_geom',4326,'MULTIPOLYGON',2); test=# insert into test (test_geom) values ('srid=4326;MULTIPOLYGON(((1 1,1 2,2 2,2 1,1 1)))'); test=# insert into test (test_geom) values ('srid=4326;MULTIPOLYGON(((2 1,3 1,3 2,2 2,2 1)))'); The following will fail no matter what shapes/srid I'm using: test=# select st_union(test_geom) from test; ERROR: Operation on mixed SRID geometries But this works fine: test=# select st_memunion(test_geom) from test; st_memunion ------------------------ 0103000020E610000001... Is there something in particular that I'm doing wrong? This only seems to be an issue with st_union as an aggregate, if I use st_union(geometry,geometry), the result looks fine. This is on a Fedora-7 (x86_64) machine with PostgreSQL 8.3, PostGIS 1.3.2, Proj-4.5.0, GEOS-3.0.0 - I have a similar setup on another machine running F8-x86_64 (except for Proj-4.6.0), and the failure is worse (the postgresql server segfaults with 'signal 11'). Would this be a bug, or have I committed some kind of user error? Is there anything I should try to figure out where the source of my problem is? Thanks in advance for any suggestions. Mike _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
