[jira] [Commented] (GEOMETRY-142) Point Set/Map

["Matt Juntunen (Jira)" <ji...@apache.org>]

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