Perhaps I misunderstand, but I thought the idea was that all GRASS modules
were supposed to respect @mapset now. Shouldn't a fix be heading in that
direction rather than finding a way to strip off the @mapset specifier?
it strips it off but at the same time populates another variable with
the value.
actually the function I am thinking of changes the map name variable
(stripping off the @mapset part) and returns the name of the mapset
(or NULL if not found). So information is not lost, that's just the
way it works in most raster modules too...
e.g. r.out.ascii/main.c:
.....
name = parm.map->answer;
mapset = G_find_cell2(name, "");
if (!mapset)
G_fatal_error(_("Raster map <%s> not found"), name);
/* open raster map */
fd = G_open_cell_old(name, mapset);
if (fd < 0)
G_fatal_error(_("Unable to open raster map <%s>"), name);
map_type = G_get_raster_map_type(fd);
.....
here G_find_cell2() strips off the @mapset and returns the (confirmed)
mapset name as it's result.
On 4/26/09 12:44 AM, "Hamish" <hamish_b@yahoo.com> wrote:
Michael wrote:
Perhaps I misunderstand, but I thought the idea was that all GRASS modules
were supposed to respect @mapset now. Shouldn't a fix be heading in that
direction rather than finding a way to strip off the @mapset specifier?
it strips it off but at the same time populates another variable with
the value.
actually the function I am thinking of changes the map name variable
(stripping off the @mapset part) and returns the name of the mapset
(or NULL if not found). So information is not lost, that's just the
way it works in most raster modules too...
e.g. r.out.ascii/main.c:
.....
name = parm.map->answer;
mapset = G_find_cell2(name, "");
if (!mapset)
G_fatal_error(_("Raster map <%s> not found"), name);
/* open raster map */
fd = G_open_cell_old(name, mapset);
if (fd < 0)
G_fatal_error(_("Unable to open raster map <%s>"), name);
map_type = G_get_raster_map_type(fd);
.....
here G_find_cell2() strips off the @mapset and returns the (confirmed)
mapset name as it's result.
Hamish
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
> Perhaps I misunderstand, but I thought the idea was that all GRASS modules
> were supposed to respect @mapset now. Shouldn't a fix be heading in that
> direction rather than finding a way to strip off the @mapset specifier?
it strips it off but at the same time populates another variable with
the value.
actually the function I am thinking of changes the map name variable
(stripping off the @mapset part) and returns the name of the mapset
(or NULL if not found). So information is not lost, that's just the
way it works in most raster modules too...
here G_find_cell2() strips off the @mapset and returns the (confirmed)
mapset name as it's result.
G_find_cell2() leaves the name untouched. G_find_cell() modifies the
name in place, so you can't use it on a const char * or if you need to
retain the @mapset part.
The ideal solution is to avoid explicitly dealing with mapsets
wherever possible. Map names taken from command line arguments or
files should just be passed down to library functions without
enquiring as to the structure of the name.
If this isn't possible, the next best solution is to determine whether
this can easily be rectified (no pun intended), e.g. by adding new
library functions.
In some cases, there are compatibility issues, e.g. existing file
formats which store the map name and mapset separately. This applies
to some of the imagery files.