[GRASS-dev] [GRASS GIS] #2660: r.external / r.external.out: support paths relative to the mapset, and variables

#2660: r.external / r.external.out: support paths relative to the mapset, and
variables
--------------------------+---------------------------------
  Reporter: sbl | Owner: grass-dev@…
      Type: defect | Status: new
  Priority: normal | Milestone: 7.0.3
Component: Raster | Version: svn-releasebranch70
Resolution: | Keywords: r.external.out
       CPU: Unspecified | Platform: Unspecified
--------------------------+---------------------------------

Comment (by glynn):

Replying to [ticket:2660 sbl]:

> If the directory given to r.external.out is relative (doesn't begin with
a "/"), it's converted to an absolute path relative to the current mapset
directory.

This isn't quite correct (although the distinction doesn't matter much in
practice). r.external.out stores the path exactly as given, but when a
linked map is created, a relative directory is converted to an absolute
directory based upon the current mapset directory.

For linked maps created with r.external, a relative filename is converted
to an absolute filename relative to the current working directory. When
accessing a linked map, no conversion is performed; the filename is passed
directly to GDALOpen(). If it was possible to create a link with a
relative filename, it would be interpreted relative to the process'
current directory.

> It would be helpful if paths relative to the mapset could be supported,
and maybe additional options, e.g. the ability to use environment
variables in paths

The first option shouldn't be that hard. It would just require moving the
relative-to-absolute conversion from read_gdal_options() (used by
Rast_create_gdal_link()) to Rast_get_gdal_link(), so that relative paths
are stored as relative then converted when accessing a linked map.

The case where a link is created manually with r.external is a bit harder.
Currently, relative paths are relative to the current working directory,
not the mapset directory, so deferring the conversion to read time would
change the behaviour. Another option is to have a GRASS variable holding
the directory for which relative paths would be interpreted.

And none of this does anything for the situation where a linked map is
outside of the mapset directory (which is the intended usage; the GRASS
database isn't supposed to contain arbitrary data files). For that, the
GDAL-link code would need some kind of remapping table. Or we would have
to allow pathnames to contain some kind of variables (not necessarily
environment variables; GRASS variables would probably be more convenient).

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2660#comment:6&gt;
GRASS GIS <https://grass.osgeo.org>