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

GRASS GIS trac at osgeo.org
Fri Dec 18 21:14:20 PST 2015


#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:  normal  |  Milestone:  7.0.3
 Component:  Vector  |    Version:  7.0.1
Resolution:          |   Keywords:  v.surf.idw r.surf.idw interpolation
       CPU:  x86-64  |   Platform:  Linux
---------------------+-------------------------------------------------
Changes (by mlennert):

 * priority:  blocker => normal


Comment:

 Replying to [comment:19 pkelly]:
 > I guess it's worth considering whether -n should really be the default
 after all...

 I think we would need a series of tests with very different use cases to
 decide. At least now, results are identical (but probably won't be in the
 case of very dense points within a cell), so at least it is mostly only a
 performance question.

 >
 > 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:

 Implemented in r67241.

 I've also taken the liberty of backporting the fixes to release70 in
 r67242.

 Downgrading priority of the bug back to normal, as now we can see why
 r.surf.idw gives these weirdly segmented results in the OP's test case.

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



More information about the grass-dev mailing list