[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981524#comment-16981524
]
Matt Juntunen commented on GEOMETRY-32:
---
Resolved with commit 77a2792463b091a37eea3859032793648a9b525d.
> 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: 1h
> 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.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981171#comment-16981171
]
Matt Juntunen commented on GEOMETRY-32:
---
bq. Isn't it possible to increase the number of allowed parameters?
It is, but I think we still want the project as a whole to follow the current
max parameter number. Each exception to that rule should be called out
explicitly.
bq. Note: Javadoc for the linearCombination methods needs fixing
Good call. Fixed.
bq. we should definitely use MathJax
Sounds good. I've never used that before. I recommend that as another follow-up
issue.
bq. What about e.g. FieldVector3D?
Oh, yeah. I didn't go far enough back:-) None of the field-related classes made
it over in the initial creation of commons-geometry because it would have
required a dependency back to commons-math for the {{Field}} functionality.
> 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: 40m
> 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.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981151#comment-16981151
]
Gilles Sadowski commented on GEOMETRY-32:
-
{quote}VectorXD.linearCombination()
{quote}
Isn't it possible to increase the number of allowed parameters? It would be
more robust than disabling the rule.
Note: Javadoc for the {{linearCombination}} methods needs fixing (it mentions
"coordinate" instead of "vector").
Also, for clarity, we should definitely use MathJax; the meaning of this:
{noformat}
* @return vector with coordinates calculated by {@code (a1 * v1) + (a2 * v2) +
(a3 * v3)}
{noformat}
would be more clearly conveyed with:
{noformat}
* @return a new vector: \( a1 \vec{v1} + a2 \vec{v2} + a3 \vec{v3} \)
{noformat}
{quote}[not] losing any [functionality]
{quote}
What about e.g.
[FieldVector3D|http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math4/geometry/euclidean/threed/FieldVector3D.html]?
Not that it would be within the scope of Commons Geometry, but we should figure
out what should not be delete from Commons Math (as not having any replacement
in the new component).
{quote}it could be done after the main code is refactored
{quote}
Sure.
> 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: 40m
> 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.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981142#comment-16981142
]
Matt Juntunen commented on GEOMETRY-32:
---
{quote}there are too many files
{quote}
Agreed :)
bq. ... suppression rules for CheckStyle. Are they necessary?
I believe they are. They all relate to the maximum number of method parameters
allowed and are either 1) internal methods used to avoid the necessity of
arrays (ex: {{Matrices.determinant()}} or 2) public convenience methods (ex:
{{VectorXD.linearCombination()}}. The linear combination methods existed before
this PR, and are similar to the {{LinearCombination}} methods from
commons-numbers-arrays, which also have a suppression rule. I'll add
documentation in checkstyle-suppressions.xml to say specifically what's being
suppressed.
bq. Does this PR entails that all the functionality of Commons Math's package
o.a.c.math4.geometry is now covered by Commons Geometry?
In general, yes. Overall, we have gained functionality instead of losing any.
The one exception that I can think of is the
{{o.a.c.g.euclidean.threed.OutlineExtractor}} class. I have not ported that
over to the new code yet and so it is not present in this PR. That is one of
the follow-up issues that I intend to make. I left it out for now because I
consider this as something of an edge-case functionality and I thought it could
be done after the main code is refactored and the API settled.
> 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: 40m
> 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.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981097#comment-16981097
]
Gilles Sadowski commented on GEOMETRY-32:
-
Thanks!
I wish I could review this, but there are too many files (and far too little
time...). ;-)
I noticed that the PR added suppression rules for CheckStyle. Are they
necessary? If so, please document them (i.e. which methods trigger them) so
that we could update them if the corresponding codes are refactored.
On a general level: Does this PR entails that all the functionality of Commons
Math's package {{o.a.c.math4.geometry}} is now covered by Commons Geometry?
> 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: 40m
> 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.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16980988#comment-16980988
]
Matt Juntunen commented on GEOMETRY-32:
---
PS is in! https://github.com/apache/commons-geometry/pull/40
> 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: 40m
> 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.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978998#comment-16978998
]
Matt Juntunen commented on GEOMETRY-32:
---
FYI, I have now completed the implementation work and removed the final
vestiges of the original partitioning code! I now need to make some final
passes through the code for cleanup and checkstyle/javadoc fixes.
> 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.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16945535#comment-16945535
]
Matt Juntunen commented on GEOMETRY-32:
---
Update:
Continuing to make progress here. Spherical 1D is now done and I have the 2D
point, hyperplane, and transform classes done with the remaining classes
stubbed out for the most part. Home stretch!
> 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.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16935312#comment-16935312
]
Matt Juntunen commented on GEOMETRY-32:
---
Thanks. That' s the current implementation.
> 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.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16935087#comment-16935087
]
Gilles commented on GEOMETRY-32:
The previous examples look nice. ;)
> 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.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16935038#comment-16935038
]
Matt Juntunen commented on GEOMETRY-32:
---
Here is another useful link for this discussion:
https://en.wikipedia.org/wiki/Orientation_(vector_space)
> 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.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16935037#comment-16935037
]
Matt Juntunen commented on GEOMETRY-32:
---
{quote}Wrong link.
{quote}
Oops. Here it is: [https://en.wikipedia.org/wiki/Region_(mathematics)]
{quote}Hence, shouldn't we hide this _implementation detail_ from the public API
{quote}
Yes. The fact that our hyperplane-bounded regions need to have their inside and
outside flipped in some situations is an implementation detail and is _not_
part of the public API. Users pass arbitrary {{Transform}} instances to the
regions and this logic is handled internally. However, the fact that some
{{Transform}} instances preserve spatial orientation _is_ part of the public
API, since it is a property of the transforms themselves. Users should not need
to worry about it unless they're implementing their own {{Transform}} classes,
which seems uneccessary. The provided classes handle all of the logic
transparently. Here are some examples. Note that I changed the method name from
{{preservesHandedness}} to {{preservesOrientation}} to be more generic.
{code:java}
// create some matrix transforms
Transform2D translate =
AffineTransformMatrix2D.createTranslation(Vector2D.of(1, 2));
translate.preservesOrientation(); // true
Transform2D reflectX = AffineTransformMatrix2D.createScale(-1, 1);
reflectX.preservesOrientation(); // false
// create some function-based transforms
Transform2D scale = FunctionTransform2D.from(p -> p.add(Vector2D.of(1, 2)));
scale.preservesOrientation(); // true
Transform2D reflectY = FunctionTransform2D.from(p -> Vector2D.of(p.getX(),
-p.getY()));
reflectY.preservesOrientation(); // false
// transform some regions
RegionBSPTree2D tree = createTree();
tree.transform(translate); // no inside/outside flipping
tree.transform(reflectY); // flips inside/outside
{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.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934983#comment-16934983
]
Gilles commented on GEOMETRY-32:
bq. see here
Wrong link.
bq. [...] just a requirement of how we're implementing the region inclusion
test, and not a property of the region itself.
Hence, shouldn't we hide this _implementation detail_ from the public API (in
the sense that application developers would/should never have any reason to set
the {{preserveHandedness}}, IIUC)?
> 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.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934868#comment-16934868
]
Matt Juntunen commented on GEOMETRY-32:
---
{quote}Really? This is actually a question: I don't know why it is a
requirement (nor where it is defined).
{quote}
I picture a region as a connected subset of the points in a space (see
[here|http://example.com/]). Therefore, the transformed region should be the
same as applying the transform to all of the points in that subset. I don't
have a formal proof of that statement, but I believe it holds nonetheless. The
flipping of the inside and outside of the regions we're talking about here is
simply a by-product of the fact that we're using oriented hyperplanes to test
points for inclusion in the region. For example, if we had a triangle in 2D and
defined our region using 3 points and barycentric coordinates instead of
oriented hyperplanes, then there would be no flipping of the inside and outside
of the region when transformed by a reflection. The same would be true if we
used unoriented line segments and winding numbers. The requirement to flip the
inside and outside of our oriented-hyperplane-bounded regions in certain
situations is just a requirement of how we're implementing the region inclusion
test, and not a property of the region itself.
> 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.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16932844#comment-16932844
]
Gilles commented on GEOMETRY-32:
bq. This is not just a matter of intuition, but also of the properties of the
region. The points that are in the interior of the region must remain in the
interior when everything is transformed.
Really? This is actually a question: I don't know why it is a requirement (nor
where it is defined). :-)
Pending your answer, I could imagine that in the same way that a reflection
transforms "left" to "right", it could also transform "in" to "out".
bq. What do you mean here?
I'm not sure! ;-)
An interface to transform coordinates, and an interface to transform oriented
shapes (?).
Maybe that does not make any sense, and I'm missing some basics about all of
this (I couldn't find an opportunity to study the code, despite having some
potential use-case...).
> 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.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931956#comment-16931956
]
Matt Juntunen commented on GEOMETRY-32:
---
{quote}My impression is that what we "intuitively" expect contradicts what is
"naturally" provided by the framework.
{quote}
This is not just a matter of intuition, but also of the properties of the
region. The points that are in the interior of the region must remain in the
interior when everything is transformed. In other words, if we consider the
region as a set of points, then the transform may modify the coordinates of the
points but must not change their membership in the set. If we did not handle
the case where the orientation is not preserved, then this may not hold true.
For example, in the previous scenario, the point (1, 1) is in the interior of
the region. However, if we did not flip the interior and exterior, then the
transformed point (-1, 1) would be on the exterior of the transformed region.
{quote}From the above, I'd feel that the clean way out of the contradiction is
to _change the orientation of the bounding lines_ rather than _flip the
interior/exterior_.
{quote}
This is exactly what is done for the immutable convex region classes (ex:
[https://github.com/darkma773r/commons-geometry/blob/geometry-32-working/commons-geometry-core/src/main/java/org/apache/commons/geometry/core/partitioning/AbstractConvexHyperplaneBoundedRegion.java#L187).]
However, the hyperplane orientations are less important in the BSP tree
classes (after the initial insertion, at least) and so the interior and
exterior nodes are simply swapped. When the boundary is extracted from the BSP
tree, then the hyperplanes are adjusted to have the correct orientations.
{quote}I get that the result would be the same when the POV is on the intuitive
meaning of the transforms being discussed here, but I wonder if the decoupling
of transformation and orientation would not lead to a better design (and
ultimately more flexibility?).
{quote}
What do you mean here?
> 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.4#803005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931256#comment-16931256
]
Gilles commented on GEOMETRY-32:
bq. We would expect the inside of the reflected region to be simply the second
quadrant, but since the orientation of the bounding lines is significant, the
inside of the region is now actually all quadrants except for the second.
My impression is that what we "intuitively" expect contradicts what is
"naturally" provided by the framework.
>From the above, I'd feel that the clean way out of the contradiction is to
>_change the orientation of the bounding lines_ rather than _flip the
>interior/exterior_.
I get that the result would be the same when the POV is on the intuitive
meaning of the transforms being discussed here, but I wonder if the decoupling
of transformation and orientation would not lead to a better design (and
ultimately more flexibility?).
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931028#comment-16931028
]
Matt Juntunen commented on GEOMETRY-32:
---
I've just implemented an updated {{Transform}} interface. We now have
{{TransformXD}} interfaces for each dimension along with
{{FunctionalTransformXD}} classes that contain the factory methods for creating
a transform from a function. There are more classes overall, but I was able to
remove those methods from {{Hyperplane}} and I think the overall design is more
maintainable.
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931026#comment-16931026
]
Matt Juntunen commented on GEOMETRY-32:
---
I must not be getting emails from JIRA. I just now saw that you commented here.
{quote}Why?
{quote}
Because otherwise points that were previously inside the region would now be
outside. For example, consider the region consisting of the first quadrant in
2D. It is bounded by the line segment going from +infinity to zero on the y
axis and the line segment 0 to +infinity on the x axis. If we transform this by
negating each x component (reflecting along the y axis), then the y axis
segment remains the same but the x axis segment now goes from 0 to -infinity,
meaning it has reversed direction. We would expect the inside of the reflected
region to be simply the second quadrant, but since the orientation of the
bounding lines is significant, the inside of the region is now actually all
quadrants except for the second. (The inside of the region is determined to lie
on the left side of the bounding line when looking along its direction.) We
therefore, need to swap the interior and exterior of the region in order to get
the expected result. This holds true for all dimensions greater than 1 where
the transform does not preserve spatial orientation.
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16926644#comment-16926644
]
Gilles commented on GEOMETRY-32:
bq. when the transform represents a reflection [...] the interior and exterior
of the region must be flipped
Why?
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
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 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 {
static Transform2D create(Function 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909559#comment-16909559
]
Matt Juntunen commented on GEOMETRY-32:
---
That's what I was planning: one giant touch-every-single-file-in-the-project
commit:-) It's still a draft PR, though, since the spherical module is not yet
converted.
> 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
(v7.6.14#76016)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909458#comment-16909458
]
Gilles commented on GEOMETRY-32:
bq. draft PR
If this is potentially ready to go into "master", could you make a new PR with
a single commit?
> 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
(v7.6.14#76016)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908196#comment-16908196
]
Matt Juntunen commented on GEOMETRY-32:
---
The euclidean module is now done!! I've removed all of the old classes from the
euclidean project. The old core partitioning classes are still required by the
spherical module so I just moved them from core to spherical for the time
being. That means that all of the modules except for spherical are in their
final states from my point of view and are ready for review on my draft PR
(https://github.com/apache/commons-geometry/pull/34). I will start work soon on
converting the spherical module over.
> 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
(v7.6.14#76016)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16879190#comment-16879190
]
Matt Juntunen commented on GEOMETRY-32:
---
Update:
Euclidean 2D is done and I'm now working on 3D. All of the new classes have
been stubbed out and it's now a matter of porting the old code and tests to the
new API and implementing the new API methods. 2D took quite a bit longer than I
was anticipating because I ended up having to go back and implement several
more things that were needed there for 3D.
After 3D, the spherical 1D and 2D packages still need to be done. I'm hoping
that those will go quickly since there isn't as much functionality there and
I'll have the Euclidean packages to use for examples.
The code in the commons-geometry-core module should be stable and ready to
review on my draft PR request:
https://github.com/apache/commons-geometry/pull/34. Euclidean 1D should also be
ready. I'd like to start the review process soon since there is a lot of code
to go over.
> 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
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855561#comment-16855561
]
Gilles commented on GEOMETRY-32:
bq. follow the pattern I've done for Euclidean 1D and 2D and apply it to the
spherical packages
You could perhaps post a "help wanted" on the ML (with a link to where the work
is going on).
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855285#comment-16855285
]
Matt Juntunen commented on GEOMETRY-32:
---
Update:
Still working on this. I'm currently almost done with the Euclidean 2D classes.
I've created the new types {{LineSegment}}, {{LineSegmentPath}},
{{LineSegmentConnector}} (and subclasses), {{SubLine}}, and
{{RegionBSPTree2D}}. I'm currently working on finishing up the geometric
property calculations for {{RegionBSPTree2D}} and handling several edge cases.
I still have yet to do the Euclidean 3D classes as well as Spherical 1D and 2D
before I can remove the old BSP tree classes. If someone wants to follow the
pattern I've done for Euclidean 1D and 2D and apply it to the spherical
packages, that would be a big help.
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16832977#comment-16832977
]
Matt Juntunen commented on GEOMETRY-32:
---
Nope. That answered my question. Thanks!
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16832486#comment-16832486
]
Gilles commented on GEOMETRY-32:
bq. Have the old and new classes together in the code base.
We won't make any release before the refactoring is done to your liking, so why
commit something half-way through?
Am I missing something?
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16832161#comment-16832161
]
Matt Juntunen commented on GEOMETRY-32:
---
{quote}Is there an alternative?
{quote}
Have the old and new classes together in the code base. They are mostly in
separate packages and we could rename any others that conflict in the same
package. I'm currently keeping them separate by having all of the old types
suffixed with {{_Old}}, but I would remove that for the merge.
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16831665#comment-16831665
]
Gilles commented on GEOMETRY-32:
bq. I'm wondering if this is still the best approach.
Is there an alternative?
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16831365#comment-16831365
]
Matt Juntunen commented on GEOMETRY-32:
---
GEOMETRY-24, GEOMETRY-33, and GEOMETRY-34 all depend on this issue. I've
actually completed the goals mentioned in this particular issue, but I have
been trying to do 24, 33, and 34 in the same PR so that we can completely
remove the old code. However, it is taking time and becoming a _very_ large set
of changes, so I'm wondering if this is still the best approach.
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16828942#comment-16828942
]
Gilles commented on GEOMETRY-32:
bq. not hold up progress on other issues that might depend on this.
Are there such issues?
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16828836#comment-16828836
]
Matt Juntunen commented on GEOMETRY-32:
---
Update: the Euclidean 1D classes are now pretty much ready to go. I had
originally hoped to get 1D, 2D, and 3D all complete before merging this code
but that still seems a ways off and I'd rather not hold up progress on other
issues that might depend on this. So, I'm thinking of making a merge request
with what I have so far and continuing the refactoring with other PRs. The only
issue with this would be that the old code BSPTree code can't yet be removed
until all of the refactoring is complete, so we would have duplicate classes
names in different packages for a while. [~erans], what do you think?
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16814024#comment-16814024
]
Matt Juntunen commented on GEOMETRY-32:
---
Update:
I now have the general BSP/region code in place and tested in the
{{commons-geometry-core}} module (including transforms and boolean operations)
and I'm working on updating the concrete implementations in
{{commons-geometry-euclidean}}. I'm about halfway through {{oned}} so far.
Here's some example code for creating a region with two disjoint intervals:
{code:java}
DoublePrecisionContext precision = new EpsilonDoublePrecisionContext(1e-6);
Interval intervalA = Interval.of(1, 2, precision);
Interval intervalB = Interval.of(3, 4, precision);
intervalA.contains(Vector1D.of(1.5)); // true
intervalB.contains(Vector1D.of(3.5)); // true
RegionBSPTree1D tree = intervalA.toTree();
tree.union(intervalB.toTree());
tree.contains(Vector1D.of(1.5)); // true
tree.contains(Vector1D.of(3.5)); // true
tree.contains(Vector1D.of(2.5)); // false
{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: 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16801613#comment-16801613
]
Gilles commented on GEOMETRY-32:
We hit a Java limitation (type erasure) which we can work around (?) by
defining specific classes just for the sake of overriding generic methods in
order to avoid explicit casting:
{code}
public class Union3D extends Union {
public RegionBSPTree3D apply(RegionBSPTree a,
RegionBSPTree b) {
return (RegionBSPTree3D) super.apply(a, b);
}
}
{code}
(!) This is untested.
And {{InplaceUnion3D}} should also be defined...
Not sure it's better than an explicit cast.
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
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}} 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16800561#comment-16800561
]
Gilles commented on GEOMETRY-32:
Design question: Have you considered making a class for each operation?
I.e. something like
{code:java}
public interface TreeOperator {
/**
* @return a new instance.
*/
RegionBSPTree create(RegionBSPTree a, RegionBSPTree b);
/**
* @return {{@code a}}, modified in place.
*/
RegionBSPTree combine(RegionBSPTree a, RegionBSPTree b);
}
{code}
And perhaps the {{RegionBSPTree}} is not necessary and the interface must be
defined in terms of {{BSPTree}} (?).
And
{code:java}
public class Union implements TreeOperator {
// ...
}
{code}
etc.
Or, perhaps even better, integrate within the
[{{java.util.function}}|https://docs.oracle.com/javase/8/docs/api/java/util/function/BinaryOperator.html]
hierarchy (incomplete generic spec):
{code:java}
public interface TreeOperator extends BinaryOperator {
// Create new instance.
TREE apply(TREE a, TREE b);
}
{code}
and
{code:java}
public interface InPlaceTreeOperator extends BinaryOperator {
// Modifies "a" in place and returns it.
TREE apply(TREE a, TREE b);
}
{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: 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16800329#comment-16800329
]
Matt Juntunen commented on GEOMETRY-32:
---
In the first quote, I'm using the term "input trees" to refer to the inputs to
the boolean operation, not the inputs to the method. Hopefully some more
examples will clarify.
{code:java}
// get references to two tree instances that should not be modified
RegionBSPTree largeTree = getLargeReusableTree();
RegionBSPTree giantTree = getGiantReusableTree();
// create a third tree to contain the result of our boolean operation
RegionBSPTree resultTree = new RegionBSPTree<>();
// compute the intersection and store the result in resultTree; largeTree
// and giantTree are not modified.
resultTree.intersectionOf(largeTree, giantTree);
{code}
{code:java}
// get a reference to an existing tree that should not be modified
RegionBSPTree largeTree = getLargeReusableTree();
// do something to get another tree that we are free to modify
RegionBSPTree tempTree = computeTemporaryTree();
// compute the intersection and store the result back in tempTree;
// largeTree is not modified.
tempTree.intersection(largeTree);
{code}
So, I use the {{intersection(RegionBSPTree)}} and
{{intersectionOf(RegionBSPTree, RegionBSPTree)}} methods above depending on
whether or not I can modify one of the inputs. I think this is important
because these trees could be quite large (I'm picturing hundreds of thousands
of nodes for 3D models), so any opportunity we get to avoid copying one is
worth taking.
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16800222#comment-16800222
]
Gilles commented on GEOMETRY-32:
I'm not sure I understand correctly: Aren't the following quotes contradictory?
bq. two versions of each boolean method: one that modifies one of the input
trees to store the answer and another one that leaves both inputs unmodified
and stores the result in a third tree
bq. In all cases, the caller is modified and the arguments are not.
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16800111#comment-16800111
]
Matt Juntunen commented on GEOMETRY-32:
---
Update:
]I'm making slow, steady progress on this. I currently have the following types
in place and tested:
- {{BSPTree}} and {{BSPTree.Node}} interfaces
- {{AbstractBSPTree}} and {{AbstractNode}} classes that implement most basic
tree functionality
- {{AttributeBSPTree}} class for storing arbitrary attributes in a tree
- {{RegionBSPTree}} class for using trees to represent spatial regions. This
contains the core functionality from the original {{BSPTree}} class.
Here are some of my remaining tasks:
- Complete the region boolean operations, ie _union_, _intersection_,
_difference_, _xor_. I finally got the basic algorithm working for this last
night after much tribulation. I need to add and test the remaining methods and
then maybe clean up the API.
- Add the {{BSPTree#transform(Transform t)}} method.
- Create/update the Subhyperplane classes in Euclidean 1D, 2D, and 3D and
spherical 1D and 2D so that they implement the new {{SubHyperplane}} and
{{ConvexSubHyperplane}} interfaces. This is actually the work of GEOMETRY-32,
but I need to do it as part of this if we want to remove the old {{BSPTree}}
hierarchy.
- Create space-specific {{RegionBSPTree1D}}, {{RegionBSPTree2D}}, etc..
classes with an API designed specifically for each type of space. I'm picturing
these types as replacing the {{IntervalsSet}}, {{PolygonsSet}}, and
{{PolyhedronsSet}} classes since they will contain all of the functionality of
the former (and more). I'm planning on removing the {{Region}} interface as
well since it doesn't seem needed anymore. This is also the work of another
issue, GEOMETRY-33, but we can't remove the old {{BSPTree}} types without it.
I could use some feedback on the following:
- The region boolean operations in the old code would modify both the caller
and the argument. For example, after the call {{tree.merge(otherTree,
leafMerger)}}, {{tree}} would be modified to contain the result, but
{{otherTree}} would also be modified and rendered unusable. I don't like this
approach because it makes it necessary to create copies of potentially very
large tree structures each time a boolean operation is applied. My current idea
is to create two versions of each boolean method: one that modifies one of the
input trees to store the answer and another one that leaves both inputs
unmodified and stores the result in a third tree. Users could then choose the
most efficient method based on what inputs need to remain unchanged. Here is
what I'm picturing:
{code:java}
public class RegionBSPTree> extends BSPTree> {
// Compute the union of this instance and the argument and store the result
in this instance.
// The argument is not modified.
void union(RegionBSPTree otherTree);
// Compute the union of the two arguments and store the result in this
instance. Neither
// argument is modified.
void unionOf(RegionBSPTree a, RegionBSPTree b);
void intersection(RegionBSPTree otherTree);
void intersectionOf(RegionBSPTree a, RegionBSPTree b);
// Compute the complement of this instance and store the result in this
instance.
void complement();
// Compute the complement of the argument and store the result in this
instance.
// The argument is not modified.
void complementOf(RegionBSPTree otherTree);
}
{code}
In all cases, the caller is modified and the arguments are not. WDYT?
> 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 messa
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16786556#comment-16786556
]
Sven Rathgeber commented on GEOMETRY-32:
{quote}I've been working out the {{BSPTree}} API and I could use some feedback.
{quote}
Hi Matt, thanks for working on the BSPTree. Sorry for no feedback so far. I
guess there is more time next week.
I like the idea of user guide / examples, too. That would have made my start
with commons-geometry a lot easier.
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16786379#comment-16786379
]
Matt Juntunen commented on GEOMETRY-32:
---
{quote}Would it be possible at this point to draft a user guide with usage
examples?
{quote}
I think it's still a little too early for a user guide, unfortunately. Once
this issue, GEOMETRY-29, GEOMETRY-33, and GEOMTRY-34 are closed the API should
be stable enough to write a pretty thorough guide.
{quote}Even better would be to accompany it with a "commons-geometry-examples"
module.
{quote}
I like this idea a lot. This would be a great place to put some of the code we
currently have only in tests, like OBJWriter and PLYParser.
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16783276#comment-16783276
]
Gilles commented on GEOMETRY-32:
Hi Matt.
Sorry for the delay in replying: I had missed your comment (and perhaps
others?).
I'm still a total newbie with BSP. :(
Would it be possible at this point to draft a user guide with usage examples?
Even better would be to accompany it with a "commons-geometry-examples" module.
It would not be part of the official code but would illustrate common tasks
(a.o. loading/saving/manipulating datasets), and be a playground for further
discussion.
WDYT?
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16780046#comment-16780046
]
Matt Juntunen commented on GEOMETRY-32:
---
Hi, guys. I've been working out the {{BSPTree}} API and I could use some
feedback. So far I have a set of {{BSPTree}} interfaces and the beginnings of
an {{AbstractBSPTree}} class that implements the primary BSP functionality but
without the logic for merging nodes, which will vary depending on what the tree
is being used for. The overall design is similar to the JDK's {{Map}},
{{Map.Entry}}, and {{AbstractMap}} types. Here are the highlights:
{code:java}
// P = Point implementation type
// T = Node attribute type
public interface BSPTreeTraversal, T> {
void visit(BSPTreeVisitor visitor);
Node findNode(P pt);
}
public interface BSPTree, T> extends BSPTreeTraversal {
Node getRoot();
public static interface Node, T> extends
BSPTreeTraversal {
BSPTree getTree();
Node getParent();
ConvexSubHyperplane getCut();
Node getPlus();
Node getMinus();
T getAttribute();
void setAttribute(T attribute);
boolean isLeaf();
boolean isPlus();
boolean isMinus();
boolean insertCut(Hyperplane cutter);
// fluent API methods
Node cut(Hyperplane cutter);
Node attr(T attribute);
}
}
{code}
Here is some example usage from a unit test (using some concrete test classes):
{code:java}
// arrange
TestBSPTree tree = new TestBSPTree();
Node node = tree.getRoot()
.cut(new TestLine(0, 0, 1, 0))
.getMinus()
.cut(new TestLine(0, 1, 0, 2))
.getPlus()
.attr(1);
// act
boolean result = node.insertCut(new TestLine(0, 2, 2, 0));
// assert
Assert.assertTrue(result);
TestLineSegment segment = (TestLineSegment) node.getCut();
PartitionTestUtils.assertPointsEqual(new TestPoint2D(0, 2),
segment.getStartPoint());
PartitionTestUtils.assertPointsEqual(new TestPoint2D(2, 0),
segment.getEndPoint());
{code}
Thoughts?
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16770789#comment-16770789
]
Sven Rathgeber commented on GEOMETRY-32:
No worries. You are right, it was a minor refactoring <5min.
{quote}I'm basically planning on ripping the guts out of all
{quote}
:)
> 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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16770689#comment-16770689
]
Matt Juntunen commented on GEOMETRY-32:
---
Oops. Yeah, I guess so. Sorry, [~rathgeber]:-( I should have explained more in
the original ticket.
> BSPTree Updates
> ---
>
> Key: GEOMETRY-32
> URL: https://issues.apache.org/jira/browse/GEOMETRY-32
> Project: Apache Commons Geometry
> Issue Type: Improvement
>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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16770652#comment-16770652
]
Gilles commented on GEOMETRY-32:
So, is PR 29 obsolete?
> BSPTree Updates
> ---
>
> Key: GEOMETRY-32
> URL: https://issues.apache.org/jira/browse/GEOMETRY-32
> Project: Apache Commons Geometry
> Issue Type: Improvement
>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)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16770620#comment-16770620
]
Matt Juntunen commented on GEOMETRY-32:
---
FYI, I decided to start work on this since its a foundational task and affects
nearly everything else. I'm working on it here:
https://github.com/darkma773r/commons-geometry/tree/geometry-32-working. I'm
placing the updated interfaces and classes in the
{{o.a.c.geometry.core.partition}} package for the time being. I have no idea
how long this will take since I'm basically planning on ripping the guts out of
all of the partitioning code and rebuilding it.
> BSPTree Updates
> ---
>
> Key: GEOMETRY-32
> URL: https://issues.apache.org/jira/browse/GEOMETRY-32
> Project: Apache Commons Geometry
> Issue Type: Improvement
>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
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16770535#comment-16770535
]
Matt Juntunen commented on GEOMETRY-32:
---
On second thought, we can probably just merge PR 29 now since the change is so
minor and the unit tests can wait until after the API has been more thoroughly
updated. Any objections, [~erans]?
> BSPTree Updates
> ---
>
> Key: GEOMETRY-32
> URL: https://issues.apache.org/jira/browse/GEOMETRY-32
> Project: Apache Commons Geometry
> Issue Type: Improvement
>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
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16769295#comment-16769295
]
Matt Juntunen commented on GEOMETRY-32:
---
Cool, thanks. As grimreaper pointed out on github, it would be good to have a
unit test for it. Unfortunately, this is the first that {{BSPTree}} has really
been touched in this refactor so there aren't any existing tests:-(
Also, I've been thinking about the whole design for this class and considering
refactoring it into {{BSPTree}} and {{BSPTreeNode}} interfaces. We would then
have a "standard" BSP tree implementation class and one designed specifically
for working with regions. That way, users can use BSPs for other purposes. To
help with this, I'm picturing a structure similar to the DOM interface, where
users do not create nodes directly but rather through the root document element
(eg, document.createElement()) , which owns all of the nodes. This is a really
powerful data structure and I'd like to make it less painful to use. I'll post
more specifics after I finish up with the hyperplane updates (eg, GEOMETRY-28
and GEOMETRY-29).
> BSPTree Updates
> ---
>
> Key: GEOMETRY-32
> URL: https://issues.apache.org/jira/browse/GEOMETRY-32
> Project: Apache Commons Geometry
> Issue Type: Improvement
>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
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16769027#comment-16769027
]
Sven Rathgeber commented on GEOMETRY-32:
added pull request for adding isLeaf() and applying it.
> BSPTree Updates
> ---
>
> Key: GEOMETRY-32
> URL: https://issues.apache.org/jira/browse/GEOMETRY-32
> Project: Apache Commons Geometry
> Issue Type: Improvement
>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
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
