this bug's URL: http://intevation.de/rt/webrt?serial_num=2391
-------------------------------------------------------------------------
Subject: r.patch: creating support files fails when 1st map isn't local
When running r.patch with "input=aspect@first_mapset,aspect@second_mapset",
building support files fails with the following errors:
r.patch: percent complete: 100%
CREATING SUPPORT FILES FOR aspect
WARNING: unable to find [aspect] in [(null)]
WARNING: category support for [aspect] in mapset [(null)] missing
grass/src/raster/r.patch/cmd/support.c header:
/*
* creates new category and color structures from the patching
* files category and color files
*
* the first patch file is used as the basis. Its cats and colr
* are read into the final cats/colr structures.
* Then the other patching layers cats/colr are added to the
* final cats/colr only if these patching layers actually
* contributed new categories to the final result
*/
thanks,
Hamish
-------------------------------------------- Managed by Request Tracker
Request Tracker wrote:
Subject: r.patch: creating support files fails when 1st map isn't local
When running r.patch with "input=aspect@first_mapset,aspect@second_mapset",
building support files fails with the following errors:
r.patch: percent complete: 100%
CREATING SUPPORT FILES FOR aspect
WARNING: unable to find [aspect] in [(null)]
WARNING: category support for [aspect] in mapset [(null)] missing
main() calls G_raster_map_type(), which calls G_find_cell(), which
overwrites the qualified name with the unqualified version. The
unqualified names are then passed to the support() function.
Personally, I don't think that G_raster_map_type() ought to behave
like this. If someone was willing to check that none of the code which
calls it relies upon this behaviour, we could change it to use
G_find_cell2() instead.
More generally, we should eliminate the use of G_find_file in library
functions (other than G_find_cell etc). I suspect that this problem
isn't limited to r.patch.
But, so long as G_raster_map_type() has its current behaviour, the
only solution is to duplicate the elements of opt1->answers so that
the original values are available to support().
--
Glynn Clements <glynn.clements@virgin.net>