[geos-devel] BoundaryNodeRule for geometry operations

[Sandro Santilli]

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

-- 

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html