[postgis-devel] Gserialized Enabled vs Disabled

[Paul Ramsey]

(And you can prove this is so by replacing your POINT in the example
with a short LINESTRING.)

On Thu, Dec 30, 2010 at 10:43 PM, Paul Ramsey <pramsey at opengeo.org> wrote:
> 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
>>
>