[postgis-users] Re: two different geometries with the same Astext

[Miguel de la Fuente]

On 7/21/05, strk at refractions.net <strk at refractions.net> wrote:
> On Thu, Jul 21, 2005 at 12:47:53PM -0300, Miguel de la Fuente wrote:
> > Well, now we're getting to something.
> >
> > When I run
> > -- SELECT postgis_full_version()
> >
> > I get
> >
> > POSTGIS="1.0.0RC3" GEOS="2.1.1" PROJ="Rel. 4.4.9, 29 Oct 2004"
> > USE_STATS DBPROC="0.2.0" RELPROC="0.2.0""
> >
> > So you're right, I'm using an old version wich has this bug not fixed.
> >
> > However, I run
> >
> > -- SELECT within(addbbox(dropbbox(g1)), addbbox(dropbbox(g2)))
> >
> > and it return TRUE
> 
> Mmm.. this doesn't confirm your problem is the box3d computation bug.
> 
> The addbbox(dropbbox()) call has the only effect of re-computing
> the cached bounding box.
> 
> Are you sure about your tests ? I summarize them:
> 
>        1) within: false
>        2) within(dropbbox): true
>        3) within(addbbox(dropbbox)): true
> 
> The above with exactly the same input data.

Yes, this is exactly what I ran with the same g1, g2.

> 
> > Then I just must upsdate POSTGIS, and that would be the whole
> > solution. doesn't it?
> 
> If you update to 1.0.3 a dump/reload would be required and
> any dump/reload would recompute bounding boxes so you should
> be ok.
> 
I updated to 1.0.2 (I didn't find 1.0.3 in POSTGIS.org page)
Now, I get

"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""

> > Thank you very much.
> >
> > One last thing, Could you tell me how to update the POSTGIS or why you
> > asked me if I ever had an older version installed??
> >
> > Thanks a lot.
> 
> Upgrade process is described in postgis manual, online:
> http://postgis.refractions.net/docs/ch02.html#upgrading
> 
> I asked about an older version installed because the old/bogus
> version might have created corrupted bounding boxes which would
> not be fixed by a simple (non dump/reloading) upgrade.
> 
I didn't do a dump/reload because I rebuild the table from its source,
and now that you found that the problem was corrupted bounding boxes I
will explain something that can be related with this.

The source of the table built are two shape files, one with
multilinestrings (in fact are linestrings but defined as
multilinestrings with one element) and the other with multipolygons
(same as previous, multipolygones with one polygon), and what I've got
to do is verify that each multilinestring is within one and only one
multipolygon, I mean each line must matches with one polygon limit.
To do that,  I convert the multipolygon to multilinestring with the
below function:

CREATE OR REPLACE FUNCTION multypolygontomultylinestring(geometry)
  RETURNS geometry AS
$BODY$
DECLARE
Polygon ALIAS FOR $1;
Cadena varchar(500);
BEGIN
return GeometryFromText('MULTILINESTRING'||substring(asText(Polygon),14,length(trim(asText(Polygon)))-14));
END;
$BODY$
  LANGUAGE 'plpgsql' VOLATILE;
ALTER FUNCTION multypolygontomultylinestring(geometry) OWNER TO postgres;

And after that I apply within().
So, better to do a dump reload I repeat all the process from the
begining with the new POSTGIS version. I use SHP2PGSQL to load the
shape, I convert the multipolygons to multilinestring, then I select a
couple by gid,  and put them into a new table, as I did the previous
time.

And it return me False again.

I didn't tell this process before to bound the problem, because no
matter where the geometries came from, the within() must return true
and I didn't want to confuse everybody, but now that you are trying to
find where the bounding boxes were corrupted, it seems to have
influence.

> --strk;
> 
> >
> >
> > On 7/20/05, strk at refractions.net <strk at refractions.net> wrote:
> > > postgis_full_version()