[postgis-users] New within problem (was:(URGENT BUGFIX (was: two different geometries with the same Astext))

[Miguel de la Fuente]

Thanks Strk, your fix work well with the example I wrote first.

But, now I`m still having problems with within().

I fix the bug as you see:

select postgis_full_version()

"POSTGIS="1.0.2" GEOS="2.1.3" PROJ="Rel. 4.4.9, 29 Oct 2004" USE_STATS
DBPROC="0.3.0" RELPROC="0.3.0""

After that, I found the following error

CREATE TABLE mu (
    g1 geometry,
    g2 geometry
);

ALTER TABLE public.mu OWNER TO postgres;

INSERT INTO mu (g1, g2) VALUES
('0105000000010000000102000000020000001BA43BA50E5A5541A12F8367C80956418284C50C685A5541F12B9D84250A5641',
'0105000000010000000102000000050000002246BA2BF05A55418B479267A20956414C8D31C4965A5541C6DC774A450956411BA43BA50E5A5541A02F8367C80956418484C50C685A5541F52B9D84250A56412246BA2BF05A55418B479267A2095641');

SELECT 
             ASTEXT(g1),
             ASTEXT(g2),
             BOX2D(g1),
             BOX2D(g2),
             WITHIN(g1,g2),
             WITHIN(BOX2D(g1),BOX2D(g2)),
             WITHIN(GEOMETRYFROMTEXT(ASTEXT(g1)),GEOMETRYFROMTEXT(ASTEXT(g2)))
FROM
mu

"MULTILINESTRING((5597242.5817652 5777185.61738196,5597600.19955552
5777558.072093))";"MULTILINESTRING((5598144.68324426
5777033.61830319,5597787.06552441 5776661.16356582,5597242.5817652
5777185.61738196,5597600.19955552 5777558.072093,5598144.68324426
5777033.61830319))";"BOX(5597242.5 5777185.5,5597600.5
5777558.5)";"BOX(5597242.5 5776661,5598145 5777558.5)";f;t;t

within(g1,g2) return FALSE
within(box2d(g1),box2d(g2)) return TRUE
within(geometryfromtext(astext(g1)),geometryfromtext(astext(g2))) return TRUE

?????

As you see both box2d are well created, and the within() works well
with the box2d, but it fails with the multilinestrings.
Do you know why?


As you see 
On 7/25/05, strk at refractions.net <strk at refractions.net> wrote:
> Thanks to Miguel de la Fuente I've found and killed a severe
> bug in bounding box computation.
> 
> EVERY BOUNDING BOX computed by postgis 1.x and cached in
> the geometry value is possibly CORRUPTED.
> 
> The corruption is due to a precision reduction which could
> make the cached bounding box smaller then the associated geometry.
> 
> This example shows the problem:
> 
>  query: SELECT box2d(GeomFromText('MULTIPOINT(5256301.4  6014563.13)'));
>  result: BOX(5256301.5 6014563,5256301.5 6014563)
> 
> As you can see the box is horizontally contained-in the multipoint.
> 
> Not all geometry constructors are affected, but many.
> GeometryFromText() is an exellent positive.
> 
> Version 1.0.3 will be out soon for a fix.
> A patch is attached.
> 
> NOTE that a simple library-only upgrade WILL NOT fix the cached
> bounding boxes.
> 
> To fix cached bounding boxes you should either dump/reload your db
> OR select addbbox(dropbbox(g)) on EVERY geometry column of EVERY spatial
> table, REINDEX every spatial index and run vacuum analyze or
> select geometry_stats() depending on pgsql version.
> 
> --strk;
> 
> 
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> 
> 
> 
>