'bugfix' for s.surf.idw

[Markus Neteler]

> 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