[GRASS-dev] some questions about future development

[Glynn Clements]

Glynn Clements wrote:

> > > BTW, a r.external would be a great addition.
> > 
> > Yes, see:
> > http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_5_4/gips/gip-0002.txt
> > 
> > Still not implemented... next GSoC project?
> 
> It's not that much work.
> 
> I have attached a "first draft" patch which adds the essential support
> to lib/gis. It has only been minimally tested, but seems to work.
> 
> To test:
> 
> 1. Copy a raster map.
> 2. Export it to an image at its native resolution.
> 3. Create a cell_misc/<name>/gdal file consisting of two lines: the
> filename followed by the band number.
> 4. Edit the cellhd/<name> file so that "compressed" is 0, and (if it's
> a CELL map) "format" is 3.
> 5. Run "r.support -s <name>" to update the range.
> 
> Tomorrow, I'll look into creating an r.external module, adding null
> support, etc.

Okay, done (well, enough to try it out without having to manually hack
the files; null support is absent).

At present, r.external is built automatically, but the code to read
linked maps is conditionalised upon GDAL_LINK, so you need to build
with "make GDAL_LINK=1". If you forget that part, r.external will
work, but attempting to read the map will fail (the cell/fcell files
are zero-length).

	$ r.external help
	
	Description:
	 Link GDAL supported raster file to a binary raster map layer.
	
	Keywords:
	 raster, import
	
	Usage:
	 r.external [-oef] [input=name] [output=name] [band=value]
	   [title="phrase"] [--overwrite] [--verbose] [--quiet]
	
	Flags:
	  -o   Override projection (use location's projection)
	  -e   Extend location extents based on new dataset
	  -f   List supported formats and exit
	 --o   Allow output files to overwrite existing files
	 --v   Verbose module output
	 --q   Quiet module output
	
	Parameters:
	   input   Raster file to be linked
	  output   Name for output raster map
	    band   Band to select
	           default: 1
	   title   Title for resultant raster map

Much of the code was salvaged from r.in.gdal, along with some of the
behaviour. E.g. if you link a non-georeferenced file into a
georeferenced (non-X/Y) location, you'll get an error about the
projection mismatch unless you also use -o.

The range, colour table and any geo-referencing information are taken
from the original data. A title can be given with title=, and an
auto-generated history (G_short_history(), G_command_history()) is
added. No histogram is generated (use "r.support -s" if you want one).

I daresay that something this fundamental will need significant
testing.

Known issues at present:

Null support is missing (r.external records any null value reported by
GDAL, but G_get_raster_row() etc ignore it; I suspect that it will
treat zero as null due to the absence of a null file).

The code which retrieves the range tells GDAL that approximate values
will suffice (requiring exact values requires reading the entire map,
in which case you may as well just use r.in.gdal).

No attempt is made to detect any changes to the underlying file. I
don't even know if this is possible, given that the details of which
files make up a GDAL "data source" are known only unto GDAL.

The input= parameter is stored verbatim. If this is a file (rather
than some non-file data source), you probably want to ensure that it's
an absolute pathname, otherwise the map will cease to work if you
change directory. Actually, the input= option is tagged as old_file,
so non-file data sources won't work.

If the original data is GDT_UInt32, it's still treated as a CELL map,
even though CELL is signed. If the input has values above 2^32-1, they
will wrap. GDT_UInt16 should work correctly, though.

Complex types aren't supported.

The r.in.gdal source implies that AVHRR data needs to be flipped
top-to-bottom; this isn't implemented.

-- 
Glynn Clements <glynn at gclements.plus.com>