[GRASS-user] new GRASS virtual raster in trunk

[Nikos Alexandris]

* Nikos Alexandris <nik at nikosalexandris.net> [2018-06-04 15:36:14 +0200]:

>* Rich Shepard <rshepard at appl-ecosys.com> [2018-06-04 05:56:16 -0700]:
>
>>On Mon, 4 Jun 2018, Markus Metz wrote:
>>
>>>A new GRASS virtual raster format has been added to trunk in r72761-4,
>>>together with a new module to build a GRASS VRT: r.buildvrt.
>>
>>Markus,
>>
>> For folks like me who have not followed this thread please explain the
>>problem for which a raster VRT is the solution.
>>
>>Best regards,
>>
>>Rich
>
>Dear Rich,
>
>(sorry Markus for my intervention -- just so excited about this new
>creation of yours!)
>
>if I may, virtual raster maps allow to treat an arbitrary number of
>raster maps as one map. Hence, it is not required to patch hundreds or
>thousands or more (?) raster map tiles, to build a single map.
>
>Why build a single map?  Because the one or the other module or workflow
>need it, in order to be able to process the entire computational extent
>of interest.
>
>
>In my case, I treat 177 tiles that cover European territories,
>for each of which there exists a raster map (of 10000 x 10000 pixels).
>Having one raster map, for the whole of Europe, will make it easier to
>extract zonal statistics, for example.

>
>
>So, in the general case of many raster maps, that form say, a "canonical"
>tile grid, zones of interest (say vector boundaries), for which is asked
>to extract statistics, are possibly split over two to up to four raster
>map tiles. It takes some respectable amount of time of handcrafting, to
>get stats for each tile, assembly then results for zones that don't
>entirely fall inside one tile.

Not to forget: somewhere before the processing, of course, a `g.region`
to set the extent over a zone of interest, is required. With A VRT, the
whole "split-up in different raster maps" problem goes away.

Nikos

>I am sure there are better explanations or even more complicated
>problems for which a Virtual raster is the answer. In short, however,
>and the way I understand things, it is a "work-around" to avoid dealing
>with huge raster data sets. Huge as in file size. And, while the total
>processing time, might not necessarily drop down, depending on the
>work-flow, the time to script a solution decreases dramatically.
>
>
>Nikos, happy to be a GRASS GIS user.



-- 
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 
-------------- 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/20180604/1c61fbc0/attachment.sig>