"," instead of "." - would that be the issue? I Poland, in opposite to the normal world, we use the coma as the decimal point deliminator. Does r.fillnulls rely on local system settings?
"," instead of "." - would that be the issue? I Poland, in opposite to
the normal world, we use the coma as the decimal point deliminator.
Does r.fillnulls rely on local system settings?
Yes, that's the problem.
I think awk might have troubles too. does this give "0,6":
echo "0,3 0,3" | awk '{printf "%.8f\n", ($1 + $2)}'
?
We can't assume "bc" or "dc" are installed, but come to think of it we
are using an arbitrary buffer distance here anyway so it doesn't really
matter if we are +/- 1m. I've just applied a fix in CVS removing the
above "awk" step. please test.
Hm, I've been half-paying attention to this, but I have a possible solution to this. A while back I modified the r.fillnulls because I wanted more than 1 cell buffer and to add a couple options to control the v.surf.rst. I had trouble with the way it was done then (can't remember the details) and switched to using r.grow. It becomes simpler since you don't need to think about how big a cell is, or in this case how the decimal is represented, and it only needs 1 temp raster. That whole block to generate the MASK condenses down to 2 lines:
"," instead of "." - would that be the issue? I Poland, in opposite to
the normal world, we use the coma as the decimal point deliminator.
Does r.fillnulls rely on local system settings?
Yes, that's the problem.
I think awk might have troubles too. does this give "0,6":
echo "0,3 0,3" | awk '{printf "%.8f\n", ($1 + $2)}'
?
We can't assume "bc" or "dc" are installed, but come to think of it we
are using an arbitrary buffer distance here anyway so it doesn't really
matter if we are +/- 1m. I've just applied a fix in CVS removing the
above "awk" step. please test.
There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened.
-Hitchhiker's Guide to the Galaxy 2nd season intro
> >> r.fillnulls fails in such a way:
> >>
> >> GRASS 6.0.cvs:~ > r.fillnulls input=N51E016_nowy
> >> output=N51E016_nowy.fld Using tmp file r_fillnulls_4707
> >> Locating and isolating NULL areas...
> >> 100%
> >> r.buffer: 00000000 - illegal distance specification
> >
..
> > what do you get if you type this at a command prompt:
> >
> > echo "0.3 0.3" | awk '{printf "%.8f\n", ($1 + $2)}'
> > 00000000 or 0.60000000 ?
>
> Neither:
>
> GRASS 6.0.cvs:~ > echo "0.3 0.3" | awk '{printf "%.8f\n", ($1 + $2)}'
> 0,00000000
>
> "," instead of "." - would that be the issue? I Poland, in opposite to
> the normal world, we use the coma as the decimal point deliminator.
> Does r.fillnulls rely on local system settings?
Yes, that's the problem.
I think awk might have troubles too. does this give "0,6":
echo "0,3 0,3" | awk '{printf "%.8f\n", ($1 + $2)}'
?
We can't assume "bc" or "dc" are installed, but come to think of it we
are using an arbitrary buffer distance here anyway so it doesn't really
matter if we are +/- 1m. I've just applied a fix in CVS removing the
above "awk" step. please test.
Hmm. In that case, scripts which use awk should probably have: