[postgis-devel] Gserialized Enabled vs Disabled

[Paul Ramsey]

There's a difference in behavior in the box retrieval functions. The
old ones would first try and pull the box off the geometry
serialization, and if that fails, compute one. The new one just tries
to pull one off the serialization, and if it fails, returns failure.
So the code in the second one skips the box test. As it stands now,
the only kind of object that doesn't have a serialized box is a point,
so this could probably be worked around.

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
>