[postgis-users] Problem with Contains/Within using shapes createdby GeomUnion
Martin Davis
mbdavis at VividSolutions.com
Tue Mar 21 09:23:54 PST 2006
This is not a bug - it is expected behaviour from the geometry
operations. Just like floating point arithmetic, geometry operations
are subject to rounding error. This means that they are not
associative. You don't expect to be able to compute 1000.0 / 99.0 *
99.0 and have the result = 1000.0. The same holds true for geometry
operations.
I suspect that the best approach is to rework your problem so that you
don't depend on the results of unioning back a lot of resultants to give
you exactly the original geometry. Possibly you can use attributes to
track the pieces to accomplish your objective (it's hard to say without
knowing what the objective is). Alternatively, you could perhaps buffer
the original geometry and use that for comparison.
Martin Davis, Senior Technical Architect
Vivid Solutions Inc. www.vividsolutions.com
Suite #1A-2328 Government Street Victoria, B.C. V8T 5G5
Phone: (250) 385 6040 - Local 308 Fax: (250) 385 6046
> -----Original Message-----
> From: postgis-users-bounces at postgis.refractions.net
> [mailto:postgis-users-bounces at postgis.refractions.net] On
> Behalf Of Mike Leahy
> Sent: March 21, 2006 9:12 AM
> To: PostGIS Users Discussion
> Subject: Re: [postgis-users] Problem with Contains/Within
> using shapes createdby GeomUnion
>
>
> Ok, thanks.
>
> Is there anything else I should do then (e.g., make bug
> report), or should I just leave it to the experts?
>
> I did find that intersecting the original shape with the
> unioned shape produced a polygon similar to the original
> shape (see below), which I guess is obvious given nature of
> the problem. I suppose as a workaround, I can update the
> geometry for shape #725 with the trimmed down intersected
> shape - though I imagine altering the original shapes isn't
> the preferred solution.
>
> test=# select gid,
> contains(the_geom,intersection(gu,the_geom)) from gutest
> cross join (select geomunion(the_geom) as gu from gutest) as
> u; gid | contains
> -----+----------
> 508 | t
> 17 | t
> 741 | t
> 195 | t
> 725 | t
> 18 | t
> (6 rows)
>
> strk at refractions.net wrote:
> > Sorry, I didn't notice the attachment.
> > I gave a look at it now, and I confirm the bug.
> > Having tried against current JTS (1.7.1) I can say the same bug is
> > there. This is probably another example of binary
> predicates working
> > at virtually infinite precision vs. constructive functions
> (geomunion)
> > applying a precision model.
> >
> > See this thread on geos-devel:
> >
> http://geos.refractions.net/pipermail/geos-devel/2006-March/001841.htm
> > l
> >
> > --strk;
> >
> > On Mon, Mar 20, 2006 at 03:08:33PM -0500, Mike Leahy wrote:
> >> strk:
> >>
> >> I'm not fully sure what should put in a self-contained test case -
> >> but if you use load sample shapes table I sent in my
> previous message
> >> (gutest.sql.zip - attached again to this message), then
> you can run
> >> all of the queries I mentioned earlier. I also tried the dropbbox
> >> function (see below), which produces the same result. Let
> me know if
> >> there's anything more I can do here.
> >>
> >> Mike
> >>
> >> On my winxp machine:
> >> createdb -U postgres test
> >> psql -U postgres -f ../share/contrib/lwpostgis.sql test
> >> psql -U postgres -f ../share/contrib/spatial_ref_sys.sql
> test psql -U
> >> postgres -f <path_to>/gutest.sql test psql -U postgres test
> >>
> >> test=# select gid, contains(dropbbox(gu),dropbbox(the_geom)) from
> >> gutest cross join (select geomunion(dropbbox(the_geom)) as gu from
> >> gutest) as u; gid | contains
> >> -----+----------
> >> 508 | t
> >> 17 | t
> >> 741 | t
> >> 195 | t
> >> 725 | f
> >> 18 | t
> >> (6 rows)
> >>
> >> test=# select version();
> >> version
> >>
> ---------------------------------------------------------------------
> >> ---------------------
> >> PostgreSQL 8.1.1 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC)
> >> 3.4.2 (mingw-special)
> >> (1 row)
> >>
> >> test=# select postgis_full_version();
> >> postgis_full_version
> >>
> ---------------------------------------------------------------------
> >> -------------
> >> POSTGIS="1.1.1" GEOS="2.2.1-CAPI-1.0.1" PROJ="Rel. 4.4.9,
> 29 Oct 2004"
> >> USE_STATS
> >> (1 row)
> >>
> >> strk at refractions.net wrote:
> >>> There might be a bug in the computed bounding box of your
> >>> geometries, Try to run the within and contains against a
> dropbbox()
> >>> version of the input. If the problem persist, please
> provide a small
> >>> self-contained testacase so we can check against
> different versions
> >>> and architectures.
> >>>
> >>> TIA
> >>>
> >>> --strk;
> >>>
> >>> On Fri, Mar 17, 2006 at 01:47:58PM -0500, Mike Leahy wrote:
> >>>> Hello list,
> >>>>
> >>>> I'm wondering if I've run into a bug with PostGIS (or maybe the
> >>>> GEOS
> >>>> module). I've been building a set of management areas
> that are created
> >>>> from a series of smaller districts merged together. I
> would normally
> >>>> expect the resulting merged polygon to topologically
> contain all of its
> >>>> constituent polygons. This has proved to be true in all
> cases for my
> >>>> data except one (so far). You can see the results of a
> test query below
> >>>> that compares a handful of shapes to their geomunion'd
> shape. In all
> >>>> cases except the shape with ID# 725, it looks fine. For
> some reason, a
> >>>> geomunion of that shape with the other contiguous shapes
> will no longer
> >>>> contain the original shape itself according to the contains() or
> >>>> within() functions. I've looked at this shape using
> Qgis and compared
> >>>> it to the corresponding geomunion shape, and it looks
> fine as far as I
> >>>> can tell visually.
> >>>>
> >>>> I've included a dump of a test table containing the six
> shapes in
> >>>> this
> >>>> management area used in the queries shown below. Let me
> know if there's
> >>>> anything I can do to work around this problem, or if there's any
> >>>> additional information I should provide.
> >>>>
> >>>> Mike
> >>>>
> >>>> ===========================================================
> >>>>
> >>>> testdb=# select gid, contains(u,the_geom), within(the_geom,u),
> >>>> isvalid(the_geom) as the_geom_isvalid, isvalid(u) as u_isvalid,
> >>>> contains(the_geom,the_geom) as the_geom_contains_itself
> from gutest
> >>>> cross join (select geomunion(the_geom) as u from gutest) as foo;
> >>>> gid | contains | within | the_geom_isvalid | u_isvalid |
> >>>> the_geom_contains_itself
> >>>>
> -----+----------+--------+------------------+-----------+----------
> >>>>
> -----+----------+--------+------------------+-----------+-----
> -----------
> >>>> 508 | t | t | t | t | t
> >>>> 17 | t | t | t | t | t
> >>>> 741 | t | t | t | t | t
> >>>> 195 | t | t | t | t | t
> >>>> 725 | f | f | t | t | t
> >>>> 18 | t | t | t | t | t
> >>>> (6 rows)
> >>>>
> >>>>
> >>>> testdb=# select version();
> >>>> version
> >>>>
> -------------------------------------------------------------------
> >>>> ---------------------------------------------------------
> >>>> PostgreSQL 8.1.3 on i386-redhat-linux-gnu, compiled by GCC
> >>>> i386-redhat-linux-gcc (GCC) 4.1.0 20060210 (Red Hat 4.1.0-0.24)
> >>>> (1 row)
> >>>>
> >>>> testdb=# select postgis_full_version();
> >>>> postgis_full_version
> >>>>
> -------------------------------------------------------------------
> >>>> ---------------
> >>>> POSTGIS="1.1.1" GEOS="2.2.1-CAPI-1.0.1" PROJ="Rel.
> 4.4.9, 29 Oct 2004"
> >>>> USE_STATS
> >>>> (1 row)
> >>>
> >>>> _______________________________________________
> >>>> postgis-users mailing list postgis-users at postgis.refractions.net
> >>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
> >>>
> >
> >
> >> _______________________________________________
> >> postgis-users mailing list postgis-users at postgis.refractions.net
> >> http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
> >
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
More information about the postgis-users
mailing list