[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17519984#comment-17519984
]
Gilles Sadowski commented on GEOMETRY-146:
------------------------------------------
Yes, it summarizes the expectations, but I don't see that it does it
differently from the previous statements. ;)
Or perhaps it does clarify one of my so-called "inconsistency", by which I
rather meant a discrepancy between the assumed API (from the user's POV) and
the functionality required from any implementation in order to provide it.
IIUC, this is in line with your remark that
{quote}It would be unfortunate to impose this cost on callers who only care
about the actual points returned and not about their ordering.
{quote}
IOW, in this case, the ability to (efficiently) navigate the result set in
ascending/descending order is not an "implementation detail": It _must_ be
built into any {{{}PointMap{}}}; that's what I meant by "tightly coupled"
(whereas an independent {{DistanceOrdering}} interface makes it look like the
functionality could be achieved without "deep" access to the actual data
structure).
Hence have {{PointMap}} explicitly handle navigation (instead of delegating it
to {{DistanceOrdering}}).
{quote}StreamableIterator is returned instead of List for two reasons: [...]
{quote}
Sure; but my point was about the high-level API that represents a cloud of
points (i.e. coordinates + data) and how to select some of them (with any kind
of criteria, not only the "fixed radius" criterion), and _then_ sort them
according yet other criteria (which could be _outside_ this API if the "view"
_is-a_
[{{List}}|https://docs.oracle.com/javase/8/docs/api/java/util/Collections.html#sort-java.util.List-]).
IOW, assuming "deep" access, can {{PointMap}} instantiate a {{List}} view
object that would *lazily* navigate the map's content?
If that "easy API" is not possible, because of the constraints inherent to an
efficient implementation of the "cloud of points" concept, what's the benefit
of a {{DistanceOrdering}} interface wrt
{code:java}
public interface PointMap {
public Stream<Map.Entry<P, V>> stream();
public Stream<Map.Entry<P, V>> streamFrom(P point, boolean reverse);
}
{code}
?
If the low-level API only provides navigation (in "natural"/near-to-far and
"reverse"/far-to-near ordering), wouldn't it be clearer to let any additional
filtering belong to a higher-level API (which [Geometry] can provide too)
{code:java}
public class Utils {
public Iterable<Map.Entry<P, V>> selectWithinDistance(PointMap<P, V> map,
P pt, double dist) {
final Stream<Map.Entry<P, V>> s = map.streamFrom(p);
// ...
}
}
{code}
?
> PointSet/Map closest points
> ---------------------------
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
> Reporter: Matt Juntunen
> Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet<P> {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable<P> closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable<P> farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
