<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Thanks Peter, this is really useful. Do you have any real-world
    benchmarks for MapServer that compare regular file access with
    vsicurl access, using optimized Geotifs? I've seen the tests for
    GDAL at <a
      href="https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF">https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF</a>,
    but what about servering  large map-sets over the web?<br>
    <br>
    <div class="moz-cite-prefix">On 8/30/2019 5:20 PM, Peter Schmitt
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CACkcqcU+aKtwiper9zywg614YQrGpZdh1SEQcAXe32D9caN9Mg@mail.gmail.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div dir="ltr">Hi Jan,
        <div><br>
          <div class="gmail_quote">
            <div dir="ltr" class="gmail_attr">On Fri, Aug 30, 2019 at
              6:20 AM Jan Hartmann <<a
                href="mailto:j.l.h.hartmann@uva.nl"
                moz-do-not-send="true">j.l.h.hartmann@uva.nl</a>>
              wrote:<br>
            </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">Hi Pete, could you
              explain what you mean by "cloud-optimized geotiffs?<br>
            </blockquote>
            <div><br>
            </div>
            <div>A Cloud Optimized GeoTIFF (COG) is a regular GeoTIFF
              file in which the data is structured for fast random
              access.  Some properties of a COG have always been useful
              for MapServer (Internally tiled & images have overview
              levels).  Other properties of a COG optimize for cloud
              access via GDAL's /vsicurl/ virtual filesystem (Image File
              Directories of the GeoTIFF are structured such that one
              HTTP request can fetch all the metadata needed to read
              subsequent blocks from an image).  This layout has been
              codified somewhat recently... Find out more here:</div>
            <div><br>
            </div>
            <div>1. The COGEO organization summarizes things: <a
                href="https://www.cogeo.org/" moz-do-not-send="true">https://www.cogeo.org</a><br>
            </div>
            <div>
              <div>2. This GDAL page talks about how to take a normal
                GeoTIFF, make it a COG and how to validate that a given
                GeoTIFF is a COG: <a
                  href="https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF"
                  moz-do-not-send="true">https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF</a></div>
              3. GDAL >= 3.1 will have a new COG driver. This
              provides some syntactic sugar to generating a COG in a
              single gdal_translate command. <a
                href="https://gdal.org/drivers/raster/cog.html"
                moz-do-not-send="true">https://gdal.org/drivers/raster/cog.html</a></div>
            <div><br>
            </div>
            <div>Cheers,</div>
            <div>Pete</div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>