[geos-devel] BoundaryNodeRule for geometry operations

[Martin Davis]

Tai, Sandro:

Glad to hear that the BoundaryNodeRule concept is useful for you.

In JTS the BoundaryOp currently does support BNRs.  I haven't seen any 
need to provide BNR support for the isClosed method.

I'm on the fence about how best to expose BNR's in the API.

I see your point that BNR's affect relate, boundary and some of the 
named spatial predicates (but not all - e.g  intersects is insensitive 
to BNR).  So simplicity would suggest adding BNR as another parameter to 
GeometryFactory  (and thus by extension to Geometrys).  As you say, this 
would avoid widening the Geometry interface, which is something I try 
hard to avoid doing.

But I'm also hesitant about adding more parameters to GeometryFactory, 
because I think the combinatorial complexity risks getting out of hand.  
Certainly I don't want to define rules about how different BNRs interact 
- which pretty much means checking them and throwing an exception if the 
GFs are different in any way.  (Although I guess the same applies to 
SRID.  PrecisionModel can be given a heterogeneous interpretation - but 
should it be the most or least precision?)

And unlike the existing parameters, BNRs have a much more limited scope 
- really just for some predicates and boundary operations, as far as I 
have found.

As Sandro points out, the named predicates can be thought of as 
convenience methods for various DE-9IM patterns, so they can be 
evaluated using different BNR's with a relatively simple syntax via relate.

Perhaps this complexity is one reason why the OGC chose to specify only 
a single BNR in the SFS!  But I have found alternate BNR's to be 
essential in some kinds of analysis (such as linear networking), so I 
think they're worth keeping.

I'd like to think about the implications of this issue a while longer 
before committing to any design changes.

Martin




On 7/13/2011 3:19 AM, Sandro Santilli wrote:
> [Turning discussion public]
>
> On Thu, Jul 07, 2011 at 11:06:25AM -0700, Tai Meng wrote:
>> Hi Martin,
>>
>> Thank you for introducing boundary rules a few years back. We lost sight of
>> it during the previous upgrade but have recently caught up.
>>
>> In my opinion, boundary rules and spatial relation operators go hand in
>> hand. Either they are both exposed in the Geometry interface, or neither
>> should be made available. Boundary rules seem to affect the meaning of
>> BOUNDARY, and by consequence INTERIOR, and by consequence all of the
>> predefined spatial relation operators.
>>
>> With respect to Geometry::getBoundary(), I think LineString::getBoundary()
>> might be the only implementation that we need to modify.
>> Geometry::isClosed() does not seem affected by boundary rules, but if it is
>> or should be, LineString::isClosed() again might be the only implementation
>> needing modification.
>>
>> Having thought about the issue more, there appear to be several advantages
>> to adding boundary rules to Geometry:
>>
>> 1) Interface uniformity for boundary rules: if Geometry is the only chunk of
>> GEOS/JTS that could be boundary rule aware, but which is not boundary rule
>> aware, then we will have achieved complete interface uniformity for boundary
>> rules.
>>
>> 2) Correctness&  completeness of spatial relation operations in Geometry: if
>> a method can have multiple behaviors, but only one behavior is implemented,
>> that method may be considered incorrect or incomplete. Adding boundary rules
>> to Geometry corrects and completes the spatial relation methods.
>>
>> 3) Preservation of existing interfaces: since we are only making interface
>> additions, existing programs would build as they are, while developers
>> interested in the new boundary rule support in Geometry can take advantage
>> of it.
>>
>> 4) Scalability of boundary rules: if we were to add boundary rules in the
>> future, and not necessarily for linear features, we'd only need to make a
>> minimal set of changes to have the appropriate concrete Geometry class(es)
>> support them e.g. modify ConcreteGeometry::getBoundary().
>>
>> Be happy to discuss further. Cheers,
>>
>> Tai
>> _______________________________________
>>
>> Tai Meng | Software Developer | BIM Specialist
>>
>> Safe Software Inc.
>> T 604.501.9985 x 246
>> tai.meng at safe.com  |  www.safe.com
>> _______________________________________
>>
>>
>> On Thu, Jul 7, 2011 at 1:27 AM, Sandro Santilli<strk at keybit.net>  wrote:
>>
>>>> *From:* Tai Meng [mailto:tai.meng at safe.com]
>>>> *Sent:* Wednesday, July 06, 2011 2:27 PM
>>>> *Subject:* GEOS patches
>>> [...]
>>>> We believe that GEOS geometries (Geometry and its children) should be
>>>> boundary rule aware. Because all geometries support spatial relation
>>>> operations such as "touches" and "overlaps", all geometries should also
>>>> support boundary rules, which change the semantics of these spatial
>>> relation
>>>> operations.
>>> While I agree on the importance of supporting BoundaryNodeRule I also
>>> think that passing the settin to the Geometry object itself is not
>>> appropriate. Really "touches" "overlaps" etc. methods of Geometry are
>>> a facility that is simplified from what's possible with the specific
>>> Relate class.
>>>
>>> I've added support for boundary node rule support in
>>> PostGIS (oldest and primary GEOS client) recently and found it effective
>>> to just modify the RelateOp and provide a matcher API
>>> (we're talking C-API here). The "touches" and "overlaps" and other are
>>> all coming from a match against the 9 extended intersection matrix, so
>>> once you compute that matrix with a specific BoundaryNodeRule you're fine
>>> to check what you need.
>>>
>>> Again: "BoundaryNodeRule" is not a property of a Geometry but the
>>> configuration of an operation. You can see how you have to deal with
>>> checking that both geometries involved in an operation have the same
>>> rule, otherwise.
>>>
>>> On the other hand, when you ask for the boundary of a geometry
>>> (Geometry::getBoundary) or for it being closed (Geometry:isClosed)
>>> I can see there's no way to specify a BoundaryNodeRule. Even with
>>> your suggested patch. That's something that's currently not easily
>>> computed and might be worth working on. Maybe adding overloaded
>>> methods in the Geometry classes taking a BoundaryNodeRule.
>>>
>>> Anyway, GEOS follows JTS design so such changes would be appropriate
>>> to discuss with Martin Davis too (added in Cc).
>>>
>>> --strk;
>>>
>>>   ()   Free GIS&  Flash consultant/developer
>>>   /\   http://strk.keybit.net/services.html
>>>