[gdal-dev] Cloud Optimised GeoTiff format

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] Cloud Optimised GeoTiff format

daunnc
Hi again!

According to the validate_cloud_optimized_geotiff.py script, overviews can't
be stored in a separate .ovr files. Are there any reasons why it was done?
Can in theory there be any problems related to overviews storage in a
separate .ovr file?

Thanks a lot in advance.



--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cloud Optimised GeoTiff format

Even Rouault-2

On vendredi 8 septembre 2017 08:50:36 CEST daunnc wrote:

> Hi again!

>

> According to the validate_cloud_optimized_geotiff.py script, overviews can't

> be stored in a separate .ovr files. Are there any reasons why it was done?

 

Because as the dictator of the cloud optimized geotiff spec, I decided so ;-) More seriously, the whole idea of C.O.G is to minimize the number of HTTP GET requests and the amount of bytes transferred. If the overviews are in a separate file, that increases it a bit. But yes, it could be discussed if it is allowed or not (similarly it will require files to be tiled starting with a certain dimension. strip organization could probably be considered valid in some context too). There could also be several levels of compliance/optimization. The current script is a bit black&white currently.

 

> Can in theory there be any problems related to overviews storage in a

> separate .ovr file?

 

That works fine too. Will require at least one extra GET request.

 

Even

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cloud Optimised GeoTiff format

daunnc
Haha, awesome!

A bit more context: I think that it could be a great thing to query TIFFs
directly (for instance) from AWS landsat bucket, and they already have
generated .ovr files which can be used, probably an additional extra query
would be not that bad. I didn't check segments ordering yet in their data,
but I hope it can work.

Thanks for your help!



--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cloud Optimised GeoTiff format

Even Rouault-2

On vendredi 8 septembre 2017 09:35:33 CEST daunnc wrote:

> Haha, awesome!

>

> A bit more context: I think that it could be a great thing to query TIFFs

> directly (for instance) from AWS landsat bucket, and they already have

> generated .ovr files which can be used, probably an additional extra query

> would be not that bad. I didn't check segments ordering yet in their data,

> but I hope it can work.

 

The .ovr from landsat-pds are standard overviews, ie not ideal from a cloud-optimized point of view. Their organization is : IFD1, IFD2, ... IFDn, data_of_IFD1 data_of_IFD2, ... data_of_IFDn instead of the expected ideal IFD1, IFD2, ... IFDn, data_of_IFDn, ... data_of_IFD2, data_of_IFD1 order that is a progressive rendering streaming friendly order. That said, for most use cases where you just access to one resolution level, this is OK. Another aspect into which the current script is really pedantic.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cloud Optimised GeoTiff format

daunnc
Clear, great!

Sounds a bit sad though. My dreams faced with reality.
At least it's definitely obvious how COG should be formed in a perfect
world.

Thanks again!



--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev