[GRASS-dev] G_() to Rast_()

[Glynn Clements]

Hamish wrote:

> why was #include <grass/raster.h> added to this file:
> 
> .../vector/lidar/lidarlib/TcholBand.c...
> 
> 
> I'm assuming there are other false positives.

I'm wondering if Martin just added Rast.h to every file which included
gis.h.

I see 294 cases which appear to be false positives (files which
include Rast.h but don't contain any occurrences of "Rast_").

Removing the "#include <grass/raster.h>" from those files and
re-compiling produces no errors; committed as r38020.

Also:

G_set_window() was moved to lib/raster, which is an error.

It's an easy mistake to make, as most of the function involves going
through the fileinfo array and re-building the column mappings and
discarding cached null data, which is something which would belong in
the raster library.

Except, the current region doesn't belong to the raster library. 

Instead, there should be a separate function to change the raster
region (there is already separate G__.window and R__.window as a
consequence of splitting up the G__ structure), and either:

1. any code which manipulates the region while maps are open (e.g. 
r.resamp.*) should explicitly change the raster region (if it actually
needs to), or

2. the various get_row functions should check that the current region
matches the cached column mappings and regenerate them in the event of
a mismatch.

My inclination would be for #1. Essentially, as well as the current
region, there would be distinct raster input and raster output
regions. These would be initialised to the current region, but could
be explicitly overriden by e.g. r.resamp.*. This would also provide a
performance gain, as r.resamp.* wouldn't keep re-generating the column
mappings every time the region is switched (input always uses the same
region settings).

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