[postgis-devel] Gserialized Enabled vs Disabled

Paragon Corporation lr at pcorp.us
Thu Dec 30 22:28:59 PST 2010


Okay this fails on both

	SELECT ST_Disjoint(ST_GeomFromEWKT('SRID=4326;POINT(-71.0821
42.3036)'), ST_GeomFromEWKT('SRID=4326;TRIANGLE((-71.0821 42.3036,-71.0821
42.3936,-71.0901 42.3036,-71.0821 42.3036))'))

With the unknown geometry type 14 - Triangle 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Friday, December 31, 2010 1:19 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Gserialized Enabled vs Disabled

Can you force the old one to fail by avoiding the short circuits?

My guess was that most of the empty failures are happening because before
empty was a geometrycollection, which meant it got kicked out of a lot of
functions early on the basis of not being a handled type.

The new types is more of a mystery, but rather than puzzling over the
differences, is there a correct behavior we want to enforce consistently?

P

On Thu, Dec 30, 2010 at 10:06 PM, Paragon Corporation <lr at pcorp.us> wrote:
> I'm seeing a bunch of differences when doing a regress compare between 
> these two
>
> Mostly with the way they handle empty geometries and the newer types 
> like TIN.
>
> It's almost as if the serialized is not doing any short-circuiting and 
> the non-serialized is.
>
> For example:
>
> 1)  SELECT ST_Disjoint(ST_GeomFromEWKT('SRID=4326;POINT(-11.1111111 
> 40)'),
> ST_GeomFromEWKT('SRID=4326;TRIANGLE((-71.0821 42.3036,-71.0821
> 42.3936,-71.0901 42.3036,-71.0821 42.3036))'))
>
>
> In the regular case - non-gserialized:
> This returns: t
>
> In the gserialized -- this returns
>
> Unknown geometry type: 14 - Triangle
>
> So it's like the non-gserialized is smart enough to realize that if 
> the bounding box does not intersect there is no need to jump into geos 
> or do anything further analysis - it knows they are disjoint.
>
> I'm seeing a lot of these silly failures.  Which are perhaps by design.
>
> Thanks,
> Regina
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel





More information about the postgis-devel mailing list