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