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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
