[
https://issues.apache.org/jira/browse/GEOMETRY-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491454#comment-17491454
]
Matt Juntunen commented on GEOMETRY-142:
----------------------------------------
I just completed initial implementations of the {{PointMap}} interface for
Euclidean 1D, 2D, and 3D and pushed them to my working branch
(https://github.com/darkma773r/commons-geometry/tree/point-map). In order to
completely hide the implementation details, I created dimension-specific
interfaces with factory methods that return instances of a package-private
class. For example, this is how you create a 3D point map in the current code:
{code:java}
Precision.DoubleEquivalence precision =
Precision.doubleEquivalenceOfEpsilon(1e-6);
// PointMap3D is an interface; the returned instance is of the package-private
class PointMap3DImpl
PointMap3D map = PointMap3D.of(precision);
{code}
I'm not totally sure of this design. It seems kind of odd to have a factory
method on an interface and I feel like the factory method name "of" isn't quite
right. However, I know that the map implementation will most likely undergo
optimizations and so needs to isolated from the public API.
In terms of the implementations, the 1D point map uses a JDK {{TreeMap}}
internally while the 2D and 3D maps use a base class that implements the
quadtree/octree approach that was the winner of the algorithm performance tests.
Feedback is welcome. I'm picturing the next step to be implementing maps for
spherical 1D and 2D. I won't be able to use the same algorithms there as for
Euclidean. I'm thinking a modified {{TreeMap}} for 1D and a BSP-based data
structure for 2D.
> Point Set/Map
> -------------
>
> Key: GEOMETRY-142
> URL: https://issues.apache.org/jira/browse/GEOMETRY-142
> Project: Apache Commons Geometry
> Issue Type: New Feature
> Reporter: Matt Juntunen
> Assignee: Matt Juntunen
> Priority: Major
> Fix For: 1.1
>
>
> It would be very useful to have set and map implementations that accepts
> points and vectors as keys and use "fuzzy" look up logic, where values are
> compared using a precision context. This would have uses in a number of
> situations, including the implementation of GEOMETRY-110.
> Options for the implementation of such classes include
> * BSP trees (as already implemented)
> * k-d trees
> * quadtrees/octrees
> * r-trees
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
