[GRASS-dev] [GRASS GIS] #2820: v.surf.idw results seem seriously wrong and don't match r.surf.idw results (was: r.surf.idw gives broken results - Don't match v.surf.idw)

[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
----------------------+-------------------------------------------------
Changes (by mlennert):

 * keywords:   => v.surf.idw r.surf.idw interpolation
 * priority:  major => blocker
 * component:  Raster => Vector


Comment:

 The more I look at this issue, the more I get the feeling that v.surf.idw
 is wrong as well. At least, I cannot really explain the output for the NC
 precipitation data shown in
 [https://trac.osgeo.org/grass/attachment/ticket/2820/idw_tests_NCdata.png
 idw_tests_NCdata.png].

 Here's a test using the NC precipitation data interpolated to maps
 rsurfidw and vsurfidw according to above instructions (tested in trunk):


 {{{
 echo "673491|55508" | v.in.ascii in=- out=test_interpolation
 v.db.addtable test_interpolation
 v.db.addcolumn test_interpolation col="idw_vect double precision"
 v.db.addcolumn test_interpolation col="idw_rast double precision"
 v.db.addcolumn test_interpolation col="owncal double precision"
 v.what.rast test_interpolation col=idw_vect rast=vsurfidw
 v.what.rast test_interpolation col=idw_rast rast=rsurfidw
 v.db.update test_interpolation col=owncal value=$(v.distance -p -a
 from=test_interpol at user1 to=precip_30ynormals at PERMANENT dmax=102000
 upload=dist,to_attr to_column=annual --quiet | tail -n +2 | awk  -F'|'
 'BEGIN{sumvals=0;sumweights=0} {weight=1/$3^2;sumweights+=weight;
 sumvals+=weight*$4} END{print sumvals/sumweights}')
 v.db.select test_interpolation
 }}}

 The result is quite unambiguous:


 {{{
 cat|idw_vect|idw_rast|owncal
 1|1545.09361138162|1388.6|1389.27
 }}}

 i.e. the calculated value is almost exactly identical to the r.surf.idw
 result, while the v.surf.idw result is very far off.

 I would guess the segmentation observed by the OP with r.surf.idw is due
 to integer rounding issues (although this should be explored), but in the
 current state, v.surf.idw needs a serious check to see where the error
 comes from !

 I'm renaming this ticket for now, but maybe it needs to be split in two...
 Bumping it up as a blocker, since this is basic functionality of a GIS
 which should "just work"...

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