Fred and Ghislain, Thanks - yes that's because of the rounding that happens in ST_GeomFromText -- the ST_GeomFromText is rounding the last couple of digits so the text rep isn't actually what the geometry is so its probably something like 796579.5624334065668 or some such thing. Looking at this in OpenJump, the polygon is practically a line so borders on being almost invalid. So I guess its some sort of rounding issue that before it gets to ST_Centroid its not invalid because the 2 mid points are technically not the same, but once it gets into ST_Centroid some rounding happens that makes it equivalent to an invalid geometry (basically a polygon with 3 points). Well I'm able to recreate this result in "POSTGIS="1.3.5SVN" GEOS="3.1.0-CAPI-1.5.0" PROJ="Rel. 4.6.0, 21 Dec 2007" I suppose the workaround for now would be to ignore anything where the area is close to 0 or centroid is empty or use ST_SnapToGrid to get rid of those extra digits in your geometry. http://postgis.refractions.net/documentation/manual-svn/ST_SnapToGrid.html None of which is terribly appealing. Thanks, Regina
________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lehodey Sent: Wednesday, December 10, 2008 5:28 AM To: PostGIS Users Discussion Subject: Re: [postgis-users] how to identify the_geom thatcause:RelateOperation called withLWGEOMCOLLECTION type Hi, just a note: inserting the same geometry : INSERT INTO bug (gid, the_geom) VALUES ( 1 , '0103000020BE6B0000010000000400000081F178483F4F2841D730212506D33C418045F71F474F2841D706623902D33C417E45F71F474F2841D806623902D33C4181F178483F4F2841D730212506D33C41' ); and INSERT INTO bug (gid, the_geom) VALUES (2,st_geomfromtext('POLYGON(( 796575.641547725 1889030.1450377, 796579.562433407 1889026.22415202, 796579.562433406 1889026.22415202, 796575.641547725 1889030.1450377))',-1)) then : SELECT gid, st_area(the_geom), astext(centroid(the_geom)), isvalid(the_geom) FROM bug returns: 1; 0.0001220703125;"GEOMETRYCOLLECTION EMPTY";t 2; 0.0001220703125;"POINT(796578.255471513 1889027.53111391)";t !! Fred. On Wed, Dec 10, 2008 at 9:06 AM, Ghislain Geniaux <[EMAIL PROTECTED]> wrote: Exact, that's the problem : scot3=# SELECT gid, the_geom scot3-# FROM bd_dispo_final scot3-# WHERE isempty(centroid(the_geom)); gid | the_geom -------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------- 16435 | 0103000020BE6B0000010000000400000081F178483F4F2841D730212506D33C418045F71F474F2841D706623902D33C417E45F71F474F2841D806623902D33C4181F178483F4F2841D730212506D33C41 (1 row) Here, you will find the ouput of pg_dump to study this geometrry. Thanks again. -- -- PostgreSQL database dump -- SET client_encoding = 'SQL_ASCII'; SET standard_conforming_strings = off; SET check_function_bodies = false; SET client_min_messages = warning; SET escape_string_warning = off; SET search_path = public, pg_catalog; SET default_tablespace = ''; SET default_with_oids = false; -- -- Name: bug; Type: TABLE; Schema: public; Owner: postgres; Tablespace:-- CREATE TABLE bug ( gid integer, the_geom geometry ); ALTER TABLE public.bug OWNER TO postgres; -- -- Data for Name: bug; Type: TABLE DATA; Schema: public; Owner: postgres -- COPY bug (gid, the_geom) FROM stdin; 16435 0103000020BE6B0000010000000400000081F178483F4F2841D730212506D33C418045F71F474F2841D706623902D33C417E45F71F474F2841D806623902D33C4181F178483F4F2841D730212506D33C41 \. -- -- PostgreSQL database dump complete -- Le 9 déc. 08 à 13:04, Obe, Regina a écrit : Ghislain, The only time I have seen this kind of behavior is when centroid returns an empty geometry collection. In those cases its because the geometry is invalid. Although none of your geometries are invalid, it could be a bug in either the centroid code or isvalid check that may or may not be fixed in 3.0.3+ of GEOS. Can you do the following SELECT gid, the_geom FROM ZS2C WHERE isempty(centroid(the_geom)) and send us as an attatched file with one of those geometries. We can cross check with GEOS 3.0.3 or 3.1 to see if the issue still remains. Thanks, Regina -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ghislain Geniaux Sent: Monday, December 08, 2008 1:29 PM To: PostGIS Users Discussion Subject: Re: [postgis-users] how to identify the_geom that cause:RelateOperation called withLWGEOMCOLLECTION type On Linux : POSTGIS="1.3.1" GEOS="3.0.0-CAPI-1.4.1" PROJ="Rel. 4.6.0, 21 Dec 2007" USE_STATS (1 row) On Macos POSTGIS="1.2.1" GEOS="3.0.0-CAPI-1.4.1" PROJ="Rel. 4.6.0, 21 Dec 2007" USE_STATS (1 row) same result with the two platform and postgis version. Thanks. Le 8 déc. 08 à 17:53, Paragon Corporation a écrit : What does SELECT postgis_full_version(); Return Thanks, Regina -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ghislain Geniaux Sent: Monday, December 08, 2008 11:03 AM To: PostGIS Users Discussion Subject: Re: [postgis-users] how to identify the_geom that cause :RelateOperation called withLWGEOMCOLLECTION type I've no collection. It's looks like a bug. Moreover my table is very large wiht more than 500 000 geometry and i found no solution to identy the wrong geom. Here you can see the query, with the same result on different plateform (LINUX DEBIAN, MACOS, with GEOS 3) otm=# select distinct geometrytype(the_geom) from ZS2c; geometrytype -------------- MULTIPOLYGON (1 row) otm=# select distinct geometrytype(the_geom) from bd_dispo_finalc ; geometrytype -------------- MULTIPOLYGON POLYGON (2 rows) otm=# create table info_nonvoue1 as otm-# select b.id_parc, z.niv from bd_dispo_finalc as b, ZS2c as z otm-# where z.niv=1 and intersects(centroid(b.the_geom),z.the_geom) and b.the_geom && z.the_geom and isvalid(b.the_geom) and isvalid (z.the_geom); ERROR: Relate Operation called with a LWGEOMCOLLECTION type. This is unsupported otm=# Le 8 déc. 08 à 13:32, Obe, Regina a écrit : Many of the GEOS relation functions do not work with collections. You must have a geometry collection in there somewhere or its a bug. Also which relation function were you trying? To figure out the type of your geometries, run SELECT * FROM sometable WHERE GeometryType(the_geom) = 'GEOMETRYCOLLECTION' -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nicolas Ribot Sent: Monday, December 08, 2008 6:22 AM To: PostGIS Users Discussion Subject: Re: [postgis-users] how to identify the_geom that cause : RelateOperation called withLWGEOMCOLLECTION type I have an error with some geometry that cause : "ERROR Relate Operation called withLWGEOMCOLLECTION type". All the geometries seem clean (valid, non empty, closed, only POLYGON, ..) My question : how to get information of which geometry cause the problem ? Is there a way to have information about the geometry during postgis is working on a SQL query ? Thanks. Hi Ghislain, What the query that failed looks like ? The message is telling that one geometry has an invalid type. In your query, you could try to ask for ST_GeometryType(geometry) and a geometry identifier to see which geometry has the wrong type. If you perform a spatial operation, it is possible that geometryCollection is produced. You could maybe split your query into smaller block to see where such collections are generated. Nicolas _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users ----------------------------------------- The substance of this message, including any attachments, may be confidential, legally privileged and/or exempt from disclosure pursuant to Massachusetts law. It is intended solely for the addressee. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users ------------------------------------------ Geniaux Ghislain INRA SAD Ecodéveloppement Site Agroparc Domaine St Paul 84914 Avignon Cedex 9 Tél : 04 32 72 25 64 Fax : 04 32 72 25 62 _______________________________________________ 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 ------------------------------------------ Geniaux Ghislain INRA SAD Ecodéveloppement Site Agroparc Domaine St Paul 84914 Avignon Cedex 9 Tél : 04 32 72 25 64 Fax : 04 32 72 25 62 _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users ----------------------------------------- The substance of this message, including any attachments, may be confidential, legally privileged and/or exempt from disclosure pursuant to Massachusetts law. It is intended solely for the addressee. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users ------------------------------------------ Geniaux Ghislain INRA SAD Ecodéveloppement Site Agroparc Domaine St Paul 84914 Avignon Cedex 9 Tél : 04 32 72 25 64 Fax : 04 32 72 25 62 _______________________________________________ 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
