[postgis-users] geos result sets

[Martin Davis]

> What you want is "interior of A interacts with interior of B". I do
not 

Not sure if this is what James really wants for his query, since he's
talking about "containment".  If it is, the appropriate relate pattern
is "T********".  

Interestingly, for some reason OGC did not specify a named predicate for
this "interiorsIntersect" relationship, even though I find that it's
what I want in several significant scenarios.  "intersects" doesn't do
it, since it is true even if the polygons touch in only a single point.

> > > interstingly, if you use a distance() = 0 function you get the
'correct' result 

You do in your particular case, but this definitely won't work in all
cases - distance() != containment.  Not does distance =
interiorsIntersect.  There's no "intrinsic tolerance" in distance - it
just happens to produce the right answer in your case.

> > > one consequence of course is that geometries would need to be very
> > > clean to prevent this sort of behaviour.

Yep. IMHO this is a feature, not a bug!  It's all very well for certain
tools to have "built-in" tolerances, but when you really need precision
they're just going to be frustrating.

I can think of a couple of ways of introducing a tolerance into your
query (effectively defining the predicate "more-or-less contained").
You could compute the area of intersection of the two polygons and see
if it's within some tolerance of the contained polygon's area.  Or, you
could buffer the containing polygon by some amount and then use the
within predicate.  The latter is probably more defensible and robust.  

In fact, I think the pre-buffering idea is probably the basis for a
semantics for predicates with tolerance values.  An interesting exercise
would be to go through the OGC predicates and define what tolerance
means for each predicate, and how to use buffering to compute it.


Martin Davis, Senior Technical Architect
Vivid Solutions Inc.
Suite #1A-2328 Government Street Victoria, B.C. V8T 5G5
Phone: (250) 385 6040 - Local 308 Fax: (250) 385 6046


> -----Original Message-----
> From: James S reid [mailto:james.reid at ed.ac.uk] 
> Sent: Thursday, February 26, 2004 7:57 AM
> To: PostGIS Users Discussion
> Subject: Re: [postgis-users] geos result sets
> 
> 
> yeah - was kinda thinking along those lines ; ) interesting 
> that ESRIs solution is not exact - does tat vary by patform 
> and product I wonder?
> 
> james
> ----- Original Message ----- 
> From: "Paul Ramsey" <pramsey at refractions.net>
> To: "PostGIS Users Discussion" <postgis-users at postgis.refractions.net>
> Sent: Thursday, February 26, 2004 3:52 PM
> Subject: Re: [postgis-users] geos result sets
> 
> 
> > Intersects() *might* work. However, it might be a bit too 
> broad. What 
> > you want is "interior of A interacts with interior of B". I do not 
> > know my Relate() function well enough, but there should be 
> a Relate() 
> > pattern that gives you what you want. Time to haul out your 
> SFSQL and 
> > read up on the 9 way dimensionally extended model... :) P.
> >
> > On Thursday, February 26, 2004, at 01:15 AM, James S reid wrote:
> >
> > > thanks for that - I can see where you are coming from even if the 
> > > results ends up a little unexpected - interstingly, if you use a 
> > > distance() = 0 function you get the 'correct' result so I guess 
> > > there is some intrinsic
> > > tolerance in the distance() function?
> > > one consequence of course is that geometries would need to be very
> > > clean to
> > > prevent this sort of behaviour. Have you any thoughts on what
> > > operators I
> > > could use that would give me the expected result without 
> have to check
> > > for
> > > data inconsistencies ? In practical terms I need to be able to
> > > establsih
> > > containment without the exacting tolerances that geos 
> seems to demand?
> > > Will
> > > the distance function work predicatbly on differnt machine
> > > architectures?
> >
> >       Paul Ramsey
> >       Refractions Research
> >       Email: pramsey at refractions.net
> >       Phone: (250) 885-0632
> >
> > _______________________________________________
> > 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
>