#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> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev