[GRASS-dev] [GRASS GIS] #2820: v.surf.idw results seem seriously wrong and don't match r.surf.idw results

[GRASS GIS]

#2820: v.surf.idw results seem seriously wrong and don't match r.surf.idw results
----------------------+-------------------------------------------------
  Reporter:  lrntct   |      Owner:  grass-dev@…
      Type:  defect   |     Status:  new
  Priority:  blocker  |  Milestone:  7.0.3
 Component:  Vector   |    Version:  7.0.1
Resolution:           |   Keywords:  v.surf.idw r.surf.idw interpolation
       CPU:  x86-64   |   Platform:  Linux
----------------------+-------------------------------------------------

Comment (by pkelly):

 Replying to [comment:15 annakrat]:
 >
 > Perhaps you could summarize your algorithm and we can put it in the
 manual. Currently there is almost nothing about the -n flag.

 Done in r67230. I guess it's worth considering whether -n should really be
 the default after all...

 And thanks a lot for finding and fixing the bug. I am sorry to have left
 such a bad bug in GRASS for so many years. Can I maybe just suggest that a
 slightly neater way of implementing the fix (and more in keeping with the
 antiquated style of the existing C code!) would be to simply make the
 variable `max` static within the function in a similar way as is already
 done for `maxdist`, like this:
 {{{
 --- main.c~     2015-12-15 20:06:09.047518721 +0000
 +++ main.c      2015-12-18 19:46:01.559351297 +0000
 @@ -458,7 +458,8 @@
  void calculate_distances(int row, int column, double north,
                          double east, int *pointsfound)
  {
 -    int j, n, max = 0;
 +    int j, n;
 +    static int max;
      double dx, dy, dist;
      static double maxdist;

 }}}
 I will say that I haven't tested that, but I think it should work and
 would be neater. But really, great work finding that as I know the code is
 hard to follow.

 Replying to [comment:16 mlennert]:
 > From what I can gather from the PhD thesis and from the code, it seems
 to me (but I'm really not sure) that the indexing is mostly useful for
 situations where you have several input points per raster cell. But in
 this case, why use interpolation and not aggregate statistics per cell (à
 la r.in.xyz) ?

 Where it is really useful, is where the data is dense in some parts of the
 region (and should be aggregated) and sparse in others (and should be
 interpolated). I guess maybe it is a pretty unusual situation, though. The
 issue with multiple input points falling within one output cell doesn't
 arise in r.surf.idw, since the distribution of the input points is limited
 by the raster resolution.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2820#comment:19>
GRASS GIS <https://grass.osgeo.org>