[GRASS-user] GRASS GIS virtual raster data sets

[Nikos Alexandris]

* Markus Metz <markus.metz.giswork at gmail.com> [2018-06-01 08:24:20 +0200]:

>On Thu, May 31, 2018 at 10:41 PM, Markus Neteler <neteler at osgeo.org> wrote:
>>
>> On Wed, May 30, 2018 at 4:21 PM, Nikos Alexandris
>> <nik at nikosalexandris.net> wrote:
>> > Dears,
>> >
>> > I guess there is no GRASS GIS built-in implementation of GDAL's VRT
>> > concept (several related ideas listed
>> > https://trac.osgeo.org/grass/wiki/Grass8Planning).
>>
>> I wish to see that as well (and discussed it a while ago with our dear
>> Markus M...
>
>I have an idea about how to implement native GRASS VRT, but no resources to
>do so...

That is great! If I may ask, is time the main requirement?

>> GRASS GIS would gain a lot having the possibility to virtually mosaik
>> raster tiles.
>>
>> > Once past some compilation issues, I am about to try to build a VRT
>> > based on native GRASS GIS raster maps (using GDAL with support for GRASS
>> > GIS raster data), then link to this VRT via `r.external` from inside a
>> > regular Mapset.
>>
>> Interesting, will that not cause loop dependencies?


I didn't think about it carefully then. Stefan's test shows that you are
right, I guess.

My naive thinking was: source images are, each, an inode. A VRT is a list of
filenames pointing to inodes. Link via r.external to the VRT which points
to the source inodes. Essentially, an indirect way to read GRASS GIS
raster maps, from inside a valid GRASS GIS session.

I guess I miss important parts of GRASS GIS' raster data model which
render the above schema to be of no use.


>>
>> I thought of true internal support for that to avoid loops.
>>
>> > As a side-note, an image without pre-computed statistics stored in its
>> > metadata, will require some time for `r.external` to work. The latter
>> > likely forces  this computation.
>> >
>> > Perhaps it is faster to use `gdalinfo`'s '-stats' option to do this.
>
>It will not be faster because you would need gdalinfo -mm -stats in order
>to get the actual values, not an approximation. Sometimes an approximation
>of the stats based on a subsample is stored in the metadata of a raster.
>
>> >
>> > I wonder if there are smart ways to build, in GRASS GIS' data base,
>> > a larger virtual raster map out of many smaller ones, without the need
>> > to actually patch the latter ones in a new raster map file.
>>
>> I guess that some C code needs to be touched in lib/raster/ to allow
>> for a VRT-style raster concept.
>
>Yes.
>
>> Maybe we missed the current GSoC train for this idea :)>
>
>The tricky part is to get a qualified student for this project.

(I wish I could be in this position! :-/)

Nikos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20180601/51e56b40/attachment.sig>