[postgis-users] how to identify the_geom thatcause:RelateOperation called withLWGEOMCOLLECTION type
Obe, Regina
robe.dnd at cityofboston.gov
Wed Dec 10 04:41:33 PST 2008
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: postgis-users-bounces at postgis.refractions.net [mailto:postgis-users-bounces at postgis.refractions.net] 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 <geniaux at avignon.inra.fr> 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: postgis-users-bounces at postgis.refractions.net [mailto:postgis-users-bounces at postgis.refractions.net] 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: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] 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: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] 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
postgis-users at postgis.refractions.net
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
postgis-users at postgis.refractions.net
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
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
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
postgis-users at postgis.refractions.net
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
postgis-users at postgis.refractions.net
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
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20081210/9124131f/attachment.html>
More information about the postgis-users
mailing list