<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi again,</div>

<div> </div>

<div>Now, I investigated a bit more. It seems to be an issue with how VRTs are read.</div>

<div>In debug=2 mode I see waaaaay more calls to:</div>

<div>G_file_name()</div>

<div>G_find_raster2()</div>

<div>file open: read (mode = r)</div>

<div>G__read_Cell_head</div>

<div>G__read_Cell_head_array</div>

<div> </div>

<div>when running r.univar on a VRT compared to reading the same maps not going through VRT.</div>

<div> </div>

<div>So I would say this is a bug with VRTs. Opened a ticket: https://github.com/OSGeo/grass/issues/4345</div>

<div> </div>

<div>Cheers,</div>

<div>Stefan</div>

<div> </div>

<div> 
<div> 
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b> Mittwoch, 18. September 2024 um 15:56 Uhr<br/>
<b>Von:</b> "Stefan Blumentrath via grass-user" <grass-user@lists.osgeo.org><br/>
<b>An:</b> grass-user@lists.osgeo.org<br/>
<b>Betreff:</b> [GRASS-user] r.buildvrt: performace issue with virtual rasters of GDAL linked raster maps on NFS</div>

<div name="quoted-content">
<div style="font-family: Verdana;font-size: 12.0px;">
<div>Hi,</div>

<div> </div>

<div>I am experiencing significant performance issues with virtual rasters build with r.buildvrt over GDAL-linked (r.external) raster maps (source is in GeoTiff format) on NFS.</div>

<div> </div>

<div>The GeoTiff data are located on a relatively fast NFS network storage, while the GRASS DB is located on a somewhat slower NFS storage system.</div>

<div> </div>

<div>In order to drill down to the issue I ran r.univar on three GDAL linked raster maps that cover my computational region. The process which consists of three r.univar runs takes ~40 seconds.</div>

<div> </div>

<div>Using the same computational region, one r.univar on a virtual raster of the same three raster map has not finished after 30 minutes. After converting the GDAL linked maps to native GRASS format (on the slower NFS) I built a VRT over the GRASS GIS format raster maps. For that VRT, performance is almost identical to to r.univar onr the individual raster maps (= no VRT). So it seems the issue is reading GDAL linked raster maps through GRASS VRTs.</div>

<div> </div>

<div>Is that a limitation of virtual rasters in GRASS GIS or is it a bug in how VRTs are read? Is there a point to open an issue for this?</div>

<div>Currently, VRT with GDAL linked data seems practically unusable... Any suggestions on what can be done is very welcome. Would be a pity if I had to abandon VRTs...</div>

<div> </div>

<div>Cheers,</div>

<div>Stefan</div>
</div>
_______________________________________________ grass-user mailing list grass-user@lists.osgeo.org <a href="https://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">https://lists.osgeo.org/mailman/listinfo/grass-user</a></div>
</div>
</div>
</div></div></body></html>