commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Juntunen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GEOMETRY-32) BSPTree Updates
Date Tue, 26 Mar 2019 05:36:00 GMT

    [ https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16801398#comment-16801398
] 

Matt Juntunen commented on GEOMETRY-32:
---------------------------------------

This is really interesting. I started on a general tree merging class yesterday named {{AbstractBSPTreeMerger}}
that encapsulates most of the logic with the semantics of each boolean operation but I hadn't
thought of making an interface for it. One thing that's a giant pain with all of this is that
I'd like the methods to return tree instances, but everything is so generified at the level
I'm working at that I can't easily return a tree of the exact type that the caller would want.
It would be a generic version that they might need to cast to something useful. For example,
I intend to make small subclasses of {{RegionBSPTree<P>}} for each space (eg {{RegionBSPTree2D}},
{{RegionBSPTree3D}}) in order to add space-specific functionality. With my current design
and an interface like that above, the caller would need to do something like this:

{code:java}
RegionBSPTree3D a = createTree();
RegionBSPTree3D b = createOtherTree();

RegionBSPTree union = (RegionBSPTree3D) new Union().apply(a, b);
{code}

It's not the worst thing in the world, but I feel like there must be a way to clean it up
a bit. I could attempt to make the tree itself part of the generic signature of the interface
but I shudder at the number of angle brackets involved in that.


> BSPTree Updates
> ---------------
>
>                 Key: GEOMETRY-32
>                 URL: https://issues.apache.org/jira/browse/GEOMETRY-32
>             Project: Apache Commons Geometry
>          Issue Type: Improvement
>          Components: core
>            Reporter: Matt Juntunen
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> The following updates should be made to the BSPTree class:
> - add an {{isLeaf()}} method to replace all of the {{node.getCut() == null}} expressions
> - add unit tests
> _Edit [2019-02-17]:_
> Additional goals:
> - Refactor the API to split the idea of a general BSPTree and a BSPTree used for defining
in/out regions. This could result in a BSPTree interface and a RegionBSPTree interface. The
goal here is to allow end-users to create their own extensions of these classes and specialize
them for their own applications (for example, to implement spatial sorting or other algorithms).
This will be one of the only planned extension points in the library.
> - Make the API easier to use and extend and reduce the necessity of casting (especially
unchecked casting) as much as possible.
> - Add the idea of convex subhyperplanes to allow for more efficient tree construction.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message