I was hoping that the bugs in s.surf.idw where fixed in the beta4 release
but I noticed that this was not the case. So I did some quick and dirty
patching to the source and now it works fine (with me ;-). The problem
was that s.surf.idw stil uses integers to store interpolated numbers
which, in my case, should be doubles (floating point numbers). (or to be
more precisely it uses a type CELL instead of a type DCELL, the last is
more appropriate to my opinion)
I changed the file main.c in the src/sites/s.surf.idw/cmd directory which
now does a correct (although I didn't do any validation yet) interpolation
and and the result is a raster map consisting of floating numbers as
z-values instead of integers.
Hi Job,
thank you for your update! I implemented it and it is working so far.
(BTW: I have a bugfix for s.in.ascii memory overflow from Bill Brown
received yesterday).
But I found in s.surf.idw that the values are .5 lower than the original
for every cell value:
I have a dem in raster. Then I used
r.to.sites -a in=dem out=demsites
I interpolated it with s.surf.idw
s.surf.idw in=demsites out=dem_new
And calculated the difference:
r.mapcalc diff="dem_new - dem"
CREATING SUPPORT FILES FOR diff
range: 0.5 0.5
Funny, isn't it? Using d.what.rast on the old DEM and the new one, I got:
d.what.rast dem_new,dem
3571412.5(E) 5765413.63131313(N)
dem_new in geosum, quant (146)
dem_new in geosum, actual (145.750000)
dem in geosum, quant (145)
dem in geosum, actual (145.250000)
3572037.5(E) 5764813.14646465(N)
dem_new in geosum, quant (155)
dem_new in geosum, actual (154.875000)
dem in geosum, quant (154)
dem in geosum, actual (154.375000)
My expectation was to get identical values here.
Any ideas?
Regards,
Markus Neteler