[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
Tue Dec 15 11:16:18 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:  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):

 Hi Moritz, Thanks for bringing this to my attention. Looks like the bug
 with the squared distance was introduced when support for powers other
 than 2 was added in r32957, and ported to GRASS 7 in r59107.

 Regarding the indexing, it's certainly true that it can give slightly
 different results depending on the layout of the points, and looking back
 maybe it shouldn't have been made the default mode of operation because of
 these differences. E.g. one obvious issue is that only points inside the
 current region are included in the interpolation, whereas without indexing
 all points are potentially included even if they lie outside the region.
 And I guess it's still possible there could be a bug in it somewhere as my
 programming skills weren't quite so well developed back then either.

 I haven't been able to test the example in the Trac ticket yet as I don't
 have GRASS 7 currently installed, only 6.4, and the GRASS6 version of the
 NC dataset at
 <https://grass.osgeo.org/sampledata/north_carolina/nc_spm_latest.tar.gz>,
 when uncompressed, seems to be actually the same as the GRASS7 version.

 My original interpolation use case was image pixels from a ground-level
 camera view that had been perspective-transformed to an overhead view,
 resulting in highly uneven point density across the region. Without the
 indexing s.surf.idw (as it was then) could take hours to run. The
 following extract from my PhD thesis gives some of the background:
 http://www.stjohnspoint.co.uk/gis/idw.pdf (although at the Firefox built-
 in PDF viewer seems to have trouble displaying it; it's converted from the
 original PostScript).

 One thing I would consider testing first if I had the data, would be to
 enlarge the region to slightly bigger than the edges of the point cloud
 (i.e. slightly bigger than the result of g.region vect=stations_vect),
 just in case there were any rounding issues with points right at the edge
 falling out of the region and not being included in the indexing.

 Paul

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



More information about the grass-dev mailing list