[GRASS-dev] Re: [GRASS GIS] #676: r.watershed: different output map
options do not allow for fully qualified map names
GRASS GIS
trac at osgeo.org
Wed Jul 8 11:27:52 EDT 2009
#676: r.watershed: different output map options do not allow for fully qualified
map names
-----------------------+----------------------------------------------------
Reporter: mlennert | Owner: grass-dev at lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.watershed
Platform: Linux | Cpu: Unspecified
-----------------------+----------------------------------------------------
Comment (by glynn):
Replying to [comment:9 hamish]:
> The problem is not G_legal_filename(). The problem is that you should
not under normal circumstances be passing fully qualified map names to
output= options.
Regardless of whether anything should or should not be doing this, passing
a qualified map name for output maps is legal, so long as the mapset is
the current mapset. E.g. G!__open_raster_new() will happily accept
map at mapset provided that mapset==G_mapset().
> And if you do, it would be useful for something* to strip it away, and
exit with an error if the value given was not the current mapset.
>
> [*] hopefully that something is done at the library level so a new fn()
wouldn't have to be added to all modules, either in G_parser() or in the
opening of a new map for write. I understand that opening a new map to
write might be downstream of a G_legal_filename() check already in the
module, but if you say that is already "cleaned" in GRASS 7 then all that
needs to be done there is add the @ stripping code to either/both of
G_parser() and or whatever the Rast_open_new_cell for write fn name is
called now.
There's no need to strip anything. Library functions should always accept
qualified map names. For output maps, the mapset must be the current
mapset, and unqualified names should use the current mapset rather than
the mapset search path (which isn't required to include the current
mapset).
The main problem is individual modules getting in the way and attempting
to enforce bogus rules.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/676#comment:12>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list