<p dir="ltr">On Oct 15, 2017 9:50 PM, "Markus Metz" <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> wrote:<br>
> On Sun, Oct 15, 2017 at 9:28 PM, Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>> wrote:<br>
> ><br>
> > On Sun, Oct 15, 2017 at 7:47 PM, Markus Metz<br>
> > <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> wrote:<br>
> > > What do you mean with "a more direct GRASS GIS integration" regarding cloud<br>
> > > storage and/or Cloud Optimized GeoTIFF?<br>
> ><br>
> > Well, I tought of r.external and r.external.out.<br>
><br>
> OK, rephrasing my question:<br>
><br>
> What do you mean with "a more direct GRASS GIS integration" regarding cloud storage and/or Cloud Optimized GeoTIFF, and regarding reading and writing such data?</p>
<p dir="ltr">So, my need is to process EO data closest possible where they are stored.<br>
Imagine a huge object storage or bucket or the like which is surrounded by cloud compute instances. Given the data size between some Terabytes up to Petabytes (e.g. Sentinel) I need to minimize whatever data transfer or extra (format) conversion.</p>
<p dir="ltr">Even's suggestion to use FUSE to mount<br>
buckets in the file system will be something to try.</p>
<p dir="ltr">However, the location concept is also causing some friction here: Sentinel data are stored in many different zones i.e. would result in many different locations. I have no solution to that yet but this issue  plus the need to minimize bandwidth usage is the key for a successful cloud storage based processing.</p>
<p dir="ltr">So I started with thinking about how to connect to current EO storages.</p>
<p dir="ltr">Best.<br>
markusN<br></p>