[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16924950#comment-16924950
]
Matt Juntunen commented on GEOMETRY-32:
---------------------------------------
Update:
I'm about 2/3 of the way through spherical 1D so far. It's been interesting
because I've been able to streamline the core interfaces and remove a few
things that don't generalize well to non-Euclidean spaces.
One thing that is causing me issues now is the {{Transform}} interface. The
current interface is simply an extension of {{Function}}. This has been working
just fine but it requires special handling when the transform represents a
reflection. In these cases, when a region is transformed, the interior and
exterior of the region must be flipped. My current solution to this is to
detect this situation in the low-level region classes themselves. I have a
{{plusPoint()}} method in the {{Hyperplane}} interface that returns an
arbitrary point on the plus side of the hyperplane. To detect a reflection, I
transform the plus point and the hyperplane and then classify the transformed
plus point against the transformed hyperplane. If the point is no longer on the
plus side of the hyperplane, the transform represents a reflection and the
transformed region is adjusted accordingly. However, this does not work well
with spherical space because the space is not infinite and not every hyperplane
is guaranteed to even have points on its plus side (eg, the negative-facing 0pi
hyperplane does not have a plus side). So, my current approach clearly won't
work here, and on closer examination, I don't think it's a great design anyway.
What do you think of the following design to replace it?
1. Remove {{plusPoint()}} (along with {{minusPoint()}} and {{onPoint()}}) from
the {{Hyperplane}} interface.
2. Have {{Transform}} still extend {{Function}} but add a method named
{{preservesHandedness()}} that returns true if the transform preserves the
handedness of the space and false otherwise.
3. Region classes flip their interior and exterior only if
{{preservesHandedness()}} of the transform returns false.
4. Each space provides a {{TransformXD}} interface that extends the core
{{Transform}} interface and adds static factory methods for creating
{{Transform}} instances from raw {{Function}} instances. The factory method
would detect that handedness behavior of the function and return an internal
{{Transform}} implementation that returns the correct value for
{{preservesHandedness()}}.
These changes would mean that a raw {{Function}} could not be used directly as
a {{Transform}}; they would need to be converted to one using a factory method
provided for each space and dimension. For example, the line below
{code:java}
Transform<Vector2D> transform = v -> v.negate();
{code}
would become
{code:java}
Transform2D transform = Transform2D.create(v -> v.negate());
{code}
where {{Transform2D}} is simply
{code:java}
public interface Transform2D extends Transform<Vector2D> {
static Transform2D create(Function<Vector2D, Vector2D> fn) {
// check the handedness behavior and return an internal implementation
// of Transform2D
}
}
{code}
> 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: 20m
> 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
(v8.3.2#803003)
