<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Sean,
<blockquote type="cite"
cite="mid:CAOodmJo2LKzczDiVfwjkp9WmDa+Yt0vur4a5Suc7-NR4mBJ+DQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>I'm wondering how this relates to STAC. Do you imagine
that GDAL users should and will use this to publish large
collections of data? When should they use this and when
should they use STAC collections instead? <br>
</div>
</div>
</div>
</blockquote>
I don't imagine this for publishing (that is not publishing the
VRRTI tile index itself), but more for internal use in the software
stack of users with large image collections. Similarly to good-ol'
XML VRT.<br>
<blockquote type="cite"
cite="mid:CAOodmJo2LKzczDiVfwjkp9WmDa+Yt0vur4a5Suc7-NR4mBJ+DQ@mail.gmail.com">
<div dir="ltr">
<div dir="auto">
<div><br>
</div>
<div>Back in the day our tile indexes were shapefiles. I don't
think this would be a good practice now. Would all vector
formats be supported?</div>
</div>
</div>
</blockquote>
yes, in theory. But as documented, it is strongly recommended to use
vector formats with efficient spatial filtering like GeoPackage,
FlatGeoBuf, PostGIS. Those 3 ones in particular have been enhanced
to support setting the metadata items used by VRTTI driver. So you
don't necessarily need to create a XML VRTTI wrapper file for those.<br>
<blockquote type="cite"
cite="mid:CAOodmJo2LKzczDiVfwjkp9WmDa+Yt0vur4a5Suc7-NR4mBJ+DQ@mail.gmail.com">
<div dir="ltr">
<div dir="auto">
<div> How about column-oriented formats?</div>
</div>
</div>
</blockquote>
that should work with them too. The fact that they are
column-oriented is just an implementation detail. That said, until
GeoParquet gets efficient spatial filtering (in the works at the
spec level: <a class="moz-txt-link-freetext" href="https://github.com/opengeospatial/geoparquet/pull/191">https://github.com/opengeospatial/geoparquet/pull/191</a>),
this isn't yet a good choice (as a provision the VRTTI driver
actually already supports .vrt.parquet)<br>
<blockquote type="cite"
cite="mid:CAOodmJo2LKzczDiVfwjkp9WmDa+Yt0vur4a5Suc7-NR4mBJ+DQ@mail.gmail.com">
<div dir="ltr">
<div dir="auto">
<div> Can I just do a gdalinfo "XXXX:example.shp" on a
MapServer tile index?</div>
</div>
</div>
</blockquote>
Yes. However, given that the metadata items suggested by VRTTI will
not be available, this will require the driver to GDALOpen() one of
the tile to figure out the number of bands, data type, etc. at
opening time. Not a big deal however if the VRTTI dataset is opened
for a long time to satisfy many requests.<br>
<blockquote type="cite"
cite="mid:CAOodmJo2LKzczDiVfwjkp9WmDa+Yt0vur4a5Suc7-NR4mBJ+DQ@mail.gmail.com">
<div dir="ltr">
<div dir="auto">
<div><br>
</div>
<div>This feature has been latent and available for a while,
yes? It's obviously useful. My main misgivings are about the
overlap with existing GDAL features and protocols (VRT, WMS,
WMTS, STAC, MBTiles). I think too many choices can create a
not great experience for users.</div>
</div>
</div>
</blockquote>
<p>Yes there is clearly overlap (like most GDAL supported formats
have strong functional overlap since they can be used with a
common API :-))</p>
<p>Here are the main differences I see:<br>
</p>
<p>- WMS: requires a client&server architecture</p>
<p>- WMTS: generally requires a client&server architecture too
(local use possible if using <a class="moz-txt-link-freetext" href="file://">file://</a> URIs), but requires regular
tiling</p>
<p>- STAC(ITems, with STAC projection extensions): functionally a
bit similar to VRTTI, but using JSON format to catalog the
sources. If you want to manage a catalog with a large set of
sources, static STAC will not work well and you'll need a STAC
server. Although with STAC, you want each "asset" to have
user-facing metadata. In a VRTTI use case, you are more interested
by the resulting mosaic than each of its source.<br>
</p>
<p>- STAC(Temporal Asset): functionally similar to WMTS (regular
tiling)<br>
</p>
<p>- MBTiles/GeoPackage/COG/etc.: single-file tiled formats<br>
</p>
<p>Even<br>
</p>
<blockquote type="cite"
cite="mid:CAOodmJo2LKzczDiVfwjkp9WmDa+Yt0vur4a5Suc7-NR4mBJ+DQ@mail.gmail.com">
<div dir="ltr">
<div dir="auto"><br>
<div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Dec 20, 2023,
11:33 AM Even Rouault via gdal-dev <<a
href="mailto:gdal-dev@lists.osgeo.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">gdal-dev@lists.osgeo.org</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,<br>
<br>
For those not actively following github tickets &
PR, I just want to <br>
point to a new pending major functionality to improve
management of <br>
virtual mosaics with a very large number of
tiles/sources (> tens of <br>
thousands of tiles), by referencing them as features of
a vector layer <br>
(typically created by gdaltindex), instead of a XML file
as in <br>
traditional VRT, augmented with additional metadata.<br>
<br>
More details in <a
href="https://github.com/OSGeo/gdal/pull/8983"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/OSGeo/gdal/pull/8983</a>
(and in initial <br>
ticket in <a
href="https://github.com/OSGeo/gdal/issues/8861"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/OSGeo/gdal/issues/8861</a>)<br>
<br>
Even<br>
<br>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>