Hello,
This kind of API sounds useful but not directly related to the
PointMap/Set types. As you mentioned, it seems like the API would most
likely use PointMap/Set internally. I believe the next step should be
to create a JIRA issue and figure out the details there.
Since it sounds like there are no objections to the current
PointMap/Set PR, I'm going to go ahead and merge it in and then
continue on with the closest point/farthest point API (GEOMETRY-146).
Regards,
Matt
On Wed, Mar 23, 2022 at 12:58 PM Gilles Sadowski <gillese...@gmail.com> wrote:
>
> Hi.
>
> Le mer. 23 mars 2022 à 03:27, Matt Juntunen
> <matt.a.juntu...@gmail.com> a écrit :
> >
> > Gilles,
> >
> > > Say, for example, that "V" holds a single (floating-point) value. We
> > > insert entries
> > > map.put(x, 2);
> > > map.put(y, 8);
> > > assuming that "x" and "y" and just barely different, according to the
> > > chosen "precision context". Then:
> > > z = (x + y) / 2; // Pseudo-code.
> > > m = map.get(z);
> > > Does "m" equal "2" or "8", depending on whether "z" is (however
> > > slightly) closer to either "x" or "y"? Or is it "5" (interpolated value)?
> >
> > It would be either 2 or 8. In the current implementations the first
> > matching entry is returned and since entries are typically searched
> > low to high, the entry corresponding to the lower of the two keys
> > would be returned. However, I do not consider this "lowest match wins"
> > behavior to be part of the public API since it depends on the
> > implementation details.
>
> For sure, any functionality must start from some low-level data
> structure with some prescribed behaviour. Here, we assume that
> the "mechanism" returns "2" or "8" (depending on the "details").
>
> My point is rather that the "cloud of points" abstraction seems to
> require a higher-level API (for which "PointMap" would, in turn,
> be an "implementation detail" too).
> Within that abstraction, querying the value at location between
> "x" and "y" would return some interpolation (i.e. any user-defined
> "combiner") of the data stored within a given "radius" of the
> queried location.
> This would make more sense (IMO) than the application having
> to deal with a result ("2" or "8") that is implementation-dependent:
> Such an additional API layer would allow the caller to specify the
> "combiner" as, for example, "the average of the values", the result
> would then be univocally defined ("5").
> [Obviously, when specifying a radius smaller than the "precision
> context", the behaviour would be identical to a direct query to the
> underlying "PointMap".]
>
> >
> > > But is it the right behaviour in all cases, or should there be a
> > > "replacement policy" (to apply whenever points are already stored
> > > within the "precision context" neighbourhood)?
> >
> > This seems to me like additional logic that could be built on top of
> > PointMap/Set, probably using the distance query methods in
> > GEOMETRY-146.
>
> Indeed; my question aimed at pointing to the importance of providing
> such an API.
>
> > Do you have a use case in mind here?
>
> In 2D: create an image (i.e. rectangular regular grid) that represents
> the (interpolated) data associated with the (scattered) points.
>
> Another (unrelated to the above discussion) feature: Allow different
> precision contexts in different regions of the space (cf. [1]).
>
> Best,
> Gilles
>
> [1] https://en.wikipedia.org/wiki/Unstructured_grid
>
> >
> > Regards,
> > Matt
> >
> > On Tue, Mar 22, 2022 at 1:05 PM Gilles Sadowski <gillese...@gmail.com>
> > wrote:
> > >
> > > Le mar. 22 mars 2022 à 14:46, Matt Juntunen
> > > <matt.a.juntu...@gmail.com> a écrit :
> > > >
> > > > Hello,
> > > >
> > > > Unless there are any other comments on the PR, I'm going to plan on
> > > > merging it into master within the next couple of days.
> > > >
> > >
> > > Thanks for providing this new functionality.
> > >
> > > Do you envision that [Geometry] will also provide ways to manipulate
> > > data stored in the map (the "V" in e.g. "PointMap<Vector3D, V>")?
> > >
> > > Say, for example, that "V" holds a single (floating-point) value. We
> > > insert entries
> > > map.put(x, 2);
> > > map.put(y, 8);
> > > assuming that "x" and "y" and just barely different, according to the
> > > chosen "precision context". Then:
> > > z = (x + y) / 2; // Pseudo-code.
> > > m = map.get(z);
> > > Does "m" equal "2" or "8", depending on whether "z" is (however
> > > slightly) closer to either "x" or "y"? Or is it "5" (interpolated value)?
> > >
> > > This is related to the feature which I mentioned in GEOMETRY-146.
> > > I get that the low-level data-structure cannot "make up" a value that
> > > is not actually stored but it seems that the next step would be an API
> > > that lets the user specify what it means to retrieve data from the map.
> > >
> > > Then, there is also
> > > map.put(z, 10);
> > > Currently "10" will replace either the value at "x" or the value at "y".
> > > But is it the right behaviour in all cases, or should there be a
> > > "replacement policy" (to apply whenever points are already stored
> > > within the "precision context" neighbourhood)?
> > >
> > > Does this make sense?
> > >
> > > Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
