[postgis-devel] Gserialized Enabled vs Disabled

[Paul Ramsey]

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
>