[GRASS-dev] raster interpolation and NULL cell filling

Hi all,

there is a new module in grass7 for raster interpolation called
r.resamp.bspline, based on the lidar tool methods. NULL cells are
filled on the go, no need to fill them first. Alternatively, the
module only interpolates NULL cells in the input raster, running quite
fast in this mode. The output raster map can then be used to fill NULL
cells in the input map (r.patch
input=raster_with_holes,raster_with_interpolated_nulls
output=gapfilled). Please test!

Markus M

Hi,

2010/5/7 Markus Metz <markus.metz.giswork@googlemail.com>:

there is a new module in grass7 for raster interpolation called
r.resamp.bspline, based on the lidar tool methods. NULL cells are
filled on the go, no need to fill them first. Alternatively, the
module only interpolates NULL cells in the input raster, running quite
fast in this mode. The output raster map can then be used to fill NULL
cells in the input map (r.patch
input=raster_with_holes,raster_with_interpolated_nulls
output=gapfilled). Please test!

great, anyway compilation fails on my machine

crosscorr.c: In function ‘cross_correlation’:
crosscorr.c:170: error: implicit declaration of function
‘P_Read_Raster_Region_Map’
crosscorr.c:170: warning: assignment makes pointer from integer without a cast

BTW, this module should probably stay in `raster/` instead of `vector\lidar`.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

On Fri, May 7, 2010 at 11:38 AM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2010/5/7 Markus Metz <markus.metz.giswork@googlemail.com>:

there is a new module in grass7 for raster interpolation called
r.resamp.bspline, based on the lidar tool methods. NULL cells are
filled on the go, no need to fill them first. Alternatively, the
module only interpolates NULL cells in the input raster, running quite
fast in this mode. The output raster map can then be used to fill NULL
cells in the input map (r.patch
input=raster_with_holes,raster_with_interpolated_nulls
output=gapfilled). Please test!

great, anyway compilation fails on my machine

crosscorr.c: In function ‘cross_correlation’:
crosscorr.c:170: error: implicit declaration of function
‘P_Read_Raster_Region_Map’

Have done make distclean? The header PolimiFunct.h has changed, your
installation is probably still using the old version in include, the
new version is in vector/lidar/lidarlib and gets copied to include
after make distclean

crosscorr.c:170: warning: assignment makes pointer from integer without a cast

BTW, this module should probably stay in `raster/` instead of `vector\lidar`.

For compilation it is easier if it is in vector/lidar because it uses
stuff in lidarlib. Otherwise it will fail because raster modules are
compiled before vector modules ->lidarlib not yet available.

Markus M

Markus Metz wrote:

> BTW, this module should probably stay in `raster/` instead of `vector\lidar`.

For compilation it is easier if it is in vector/lidar because it uses
stuff in lidarlib. Otherwise it will fail because raster modules are
compiled before vector modules ->lidarlib not yet available.

Should vector/lidar/lidarlib be moved to lib/lidarlib?

--
Glynn Clements <glynn@gclements.plus.com>

On Fri, May 7, 2010 at 2:19 PM, Glynn Clements <glynn@gclements.plus.com> wrote:

Markus Metz wrote:

> BTW, this module should probably stay in `raster/` instead of `vector\lidar`.

For compilation it is easier if it is in vector/lidar because it uses
stuff in lidarlib. Otherwise it will fail because raster modules are
compiled before vector modules ->lidarlib not yet available.

Should vector/lidar/lidarlib be moved to lib/lidarlib?

Makes sense I guess. And rename PolimiFunct.h to something like lidar.h.

And while we're on it, I would like to have a new library in trunk for
a balanced binary search tree. The code is currently hidden in
lib/vector/diglib, files rbtree.c and rbtree.h, but I introduced it
not only to vector stuff, but also to some raster libs/modules, e.g.
lib/segment and r.stream.extract (not yet in trunk), creating a bit of
a mess on the way because of code duplication. But I don't know what
Makefiles in include/Make would need modification.

Markus M