[GRASS-dev] Cloud optimized GeoTIFF support

Even Rouault even.rouault at spatialys.com
Sun Oct 15 12:45:58 PDT 2017


On dimanche 15 octobre 2017 21:28:24 CEST Markus Neteler wrote:
> On Sun, Oct 15, 2017 at 7:47 PM, Markus Metz
> 
> <markus.metz.giswork at gmail.com> wrote:
> > What do you mean with "a more direct GRASS GIS integration" regarding
> > cloud
> > storage and/or Cloud Optimized GeoTIFF?
> 
> Well, I tought of r.external and r.external.out.
> 
> Markus Metz wrote:
> > Have you tried GDAL's virtual network based file systems [0]?
> 
> ... I didn't yet since traveling all the time. Maybe simple and solved
> but I have no stable connections at time to try out.
> 

Also note that the performance of network accesses depends a lot of how close 
the machine is from the server. For example if you use the VMs of a cloud 
provider in the same region as the bucket you access, the timing measuremetns 
will be 10 times or more better than if you try from a consumer ADSL 
connection.

For Linux & Mac, there are also various projects that use FUSE to mount 
buckets in the file system
https://github.com/kahing/goofys
https://github.com/googlecloudplatform/gcsfuse

I tried quickly goofys and it worked pretty well. It tends to have a more 
aggressive read-ahead strategy than GDAL /vsis3/, which makes reading a lot of 
sequential data faster than with /vsis3/. In latest GDAL trunk, the GeoTIFF 
driver is aware of the network nature of the files and thus can better 
optimize windowed access, so this makes it a bit faster in cases where you 
only access part of the imagery (for example with MapServer that must satisfy 
a WMS request on a BBOX, which was the use case for this recent round of 
optimization, or if you have a processing spread over several VMs with a 
spatial subdivision)

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the grass-dev mailing list