<div dir="ltr"><div>Johannes: thanks for this analysis, good ideas here!</div><div><br></div><div>If I understand correctly, this means that a MapProxy cache is already seeded, and a pygeoapi MapProxy tile provider would translate the OGC API - Tiles requests into the given MapProxy cache.</div><div><br></div><div>pygeoapi could then define such a provider with:</div><div><br></div><div><pre><span class="gmail-nt">providers</span><span class="gmail-p">:</span>
<span class="gmail-w"> </span><span class="gmail-p gmail-p-Indicator">-</span><span class="gmail-w"> </span><span class="gmail-nt">type</span><span class="gmail-p">:</span><span class="gmail-w"> </span><span class="gmail-l gmail-l-Scalar gmail-l-Scalar-Plain">tile</span>
<span class="gmail-w"> </span><span class="gmail-nt">name</span><span class="gmail-p">:</span><span class="gmail-w"> MapProxy</span>Cache
<span class="gmail-w"> </span><span class="gmail-nt">data</span><span class="gmail-p">:</span><span class="gmail-w"> </span>/path/to/cache.gpkg<span class="gmail-w"><br> </span><span class="gmail-nt">options</span><span class="gmail-p">:</span>
<span class="gmail-w"> </span><span class="gmail-nt">metadata_format</span><span class="gmail-p">:</span><span class="gmail-w"> </span><span class="gmail-l gmail-l-Scalar gmail-l-Scalar-Plain">default</span>
<span class="gmail-w"> </span><span class="gmail-nt">zoom</span><span class="gmail-p">:</span>
<span class="gmail-w"> </span><span class="gmail-nt">min</span><span class="gmail-p">:</span><span class="gmail-w"> </span><span class="gmail-l gmail-l-Scalar gmail-l-Scalar-Plain">0</span>
<span class="gmail-w"> </span><span class="gmail-nt">max</span><span class="gmail-p">:</span><span class="gmail-w"> </span><span class="gmail-l gmail-l-Scalar gmail-l-Scalar-Plain">5</span>
<span class="gmail-w"> </span><span class="gmail-nt">schemes</span><span class="gmail-p">:</span>
<span class="gmail-w"> </span><span class="gmail-p gmail-p-Indicator">-</span><span class="gmail-w"> </span><span class="gmail-l gmail-l-Scalar gmail-l-Scalar-Plain">WorldCRS84Quad</span><br> type: geopackage<br> table_name: tiles_table
<span class="gmail-w"> </span><span class="gmail-nt">format</span><span class="gmail-p">:</span>
<span class="gmail-w"> </span><span class="gmail-nt">name</span><span class="gmail-p">:</span><span class="gmail-w"> </span>png
<span class="gmail-w"> </span><span class="gmail-nt">mimetype</span><span class="gmail-p">:</span><span class="gmail-w"> </span><span class="gmail-l gmail-l-Scalar gmail-l-Scalar-Plain">image/png</span></pre></div><div><br></div><div>Another interesting option would be to have a pygeoapi MapProxy lazy-caching option (where tiles are generated as needed). Of course, this would require more configuration on the underlying service(s) to be cached by MapProxy.</div><div><br></div><div>Thanks</div><div><br></div><div>..Tom</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 24, 2023 at 4:02 AM Johannes Weskamm via MapProxy-dev <<a href="mailto:mapproxy-dev@lists.osgeo.org">mapproxy-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">
<div>
<p>Hi,</p>
<p>So here are my first findings on the topic of OGC API and
pygeoapi.</p>
<p>You can already publish cached WMS that come from MapProxy
through pygeoapi via OGC API Map
(<a href="https://docs.pygeoapi.io/en/stable/data-publishing/ogcapi-maps.html" target="_blank">https://docs.pygeoapi.io/en/stable/data-publishing/ogcapi-maps.html</a>).</p>
<p>I think that is a bit inefficient, as OGC API Tiles could
potentially access the tiles directly as they have been stored in
the chosen MapProxy backend (mbtiles, files, ...).</p>
<p>So in order to avoid the image assembling and rescaling in
mapproxy (and do it in the client instead, which may not perform
better, maybe even worse), support for those tile backends need to
be implemented in pygeoapi.</p>
<p>Currently the only provider for OGC API Tiles in pygeoapi seems
to be the MVT-Provider, which obviously does not work with
mapproxy. So a provider / reader like mbtiles, xyz structures or
similar for non vector data needs to be implemented. Some things
do exists in pygeoapi which should help to get on the train
quickly.</p>
<p>I think that an implementation in pygeoapi would solve your needs
most efficient. <br>
</p>
<p>Afterwards we could provide documentation and examples how to use
MapProxy and pygeoapi together to be OGC-API comaptible.</p>
<p>My 2 cents,</p>
<p>Greetings,</p>
<p>Johannes</p>
<p><br>
</p>
<div>Am 22.11.23 um 16:18 schrieb Johannes
Weskamm:<br>
</div>
<blockquote type="cite">
<p>Hi,</p>
<p>This sounds very good in my opinion! Having OGC API Support in
MapProxy would be a really nice feature and enable MapProxy to
catch up with the future of OGC Standards.</p>
<p>In general, Pull Request are always welcome and the features
you mentioned sound interesting, so i see no obvious reasons
that would block your contributions.</p>
<p>Some bigger goals, like OGC API Support, would need some
discussion before starting with development. Before reinventing
the wheel one should examine what pygeoapi has to offer.</p>
<p>The current documentation (<a href="https://docs.pygeoapi.io/en/stable/data-publishing/ogcapi-tiles.html" target="_blank">https://docs.pygeoapi.io/en/stable/data-publishing/ogcapi-tiles.html</a>)
even mentions MapProxy as a possible data source, but the
examples are lacking, so i am not sure if support already exists
or needs to be done. But even if its still missing, i guess it
would be the more elegant way to use pygeoapi together with
mapproxy or implement and extend the relevant classes, as the
main thing is already done in pygeoapi and updated regularly.</p>
<p><br>
</p>
<p>I may find some time in the upcoming weeks to shed some more
light on that.</p>
<p>I am also interested what other people think about that.</p>
<p><br>
</p>
<p>Greetings,</p>
<p>Johannes<br>
</p>
<p><br>
</p>
<p><br>
</p>
<div>Am 13.11.23 um 09:52 schrieb Alistair
Everett via MapProxy-dev:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br clear="all">
<div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div style="color:rgb(80,0,80)"><span style="color:rgb(34,34,34)">Hi all,</span></div>
<br>
At the Norwegian Meteorological Institute
we're considering using MapProxy to
provide model and other map based data to
some of our frontend services. I'm aware
we've been somewhat involved with MapProxy
before and used it for some of our
services, unfortunately most of those
involved aren't working here anymore so
we're looking at building from scratch and
modernising our services. First with a new
WMS offering, but we would also like to be
able to provide OGC API endpoints in the
future.<br>
<br>
There are a couple of features which we
would be interested in having in MapProxy,
particularly related to dimensions - for
example, other forms of caching (S3 and
mbtiles), seeding, and potentially reading
available dimensions from WMS sources. I
know some of these features are available
as standard but I believe they currently
don't necessarily work with dimensions. As
part of this project I'm hoping that we
will have some developer time to put into
this, so I'm interested in hearing what
the community thinks of this, how it might
fit in with any roadmap the MapProxy
community might already have, and if you
are open to us submitting our own MRs for
these features?<br>
<br>
I'm also interested in what the community
thinks of OGC-API endpoints, do you see
this as something which MapProxy would
like to offer, if the resources were
available to develop it? Or do you see
this as something which would rather be
offered through other packages, for
example pygeoapi with MapProxy providing a
tile cache in the background?<br>
<br>
Interested to hear your thoughts,<br>
<br>
Kind regards,<br>
Alistair</div>
<div dir="ltr"><br>
<div style="color:rgb(80,0,80)"><span style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">--------------</span></div>
<div style="color:rgb(80,0,80)"><b style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">Dr
Alistair Everett</b><br>
</div>
<div>Senioringeniør / Senior Software
Engineer<br>
Avdeling for Geoutvikling</div>
<div><br>
</div>
<div><span style="color:rgb(0,0,0)"><b>Phone:</b>
+47 939 68 985</span><br>
</div>
<div>
<div><font color="#000000"><b>Email:</b> <a href="mailto:alistaire@met.no" style="color:rgb(17,85,204)" target="_blank">alistair.everett@met.no</a></font></div>
</div>
<div><br>
</div>
<div><b>Meteorologisk Institutt</b>,<br>
</div>
<div>Henrik Mohns plass 1, </div>
<div>0313 Oslo<br>
</div>
<div><span style="color:rgb(0,0,0)"><br>
</span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
MapProxy-dev mailing list
<a href="mailto:MapProxy-dev@lists.osgeo.org" target="_blank">MapProxy-dev@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/mapproxy-dev" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapproxy-dev</a>
</pre>
</blockquote>
</blockquote>
<pre cols="72">--
Dipl.-Geogr. Johannes Weskamm
— Anwendungsentwickler —
terrestris GmbH & Co. KG
Kölnstraße 99
53111 Bonn
Tel: +49 (0)228 / 96 28 99 -51
Fax: +49 (0)228 / 96 28 99 -57
Email: <a href="mailto:weskamm@terrestris.de" target="_blank">weskamm@terrestris.de</a>
Web: <a href="https://www.terrestris.de" target="_blank">https://www.terrestris.de</a>
Amtsgericht Bonn, HRA 6835
Komplementärin: terrestris Verwaltungsgesellschaft mbH
vertreten durch: Torsten Brassat, Marc Jansen
Informationen über Ihre gespeicherten Daten finden Sie auf
unserer Homepage unter folgendem Link:
<a href="https://www.terrestris.de/datenschutzerklaerung/" target="_blank">https://www.terrestris.de/datenschutzerklaerung/</a></pre>
</div>
_______________________________________________<br>
MapProxy-dev mailing list<br>
<a href="mailto:MapProxy-dev@lists.osgeo.org" target="_blank">MapProxy-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/mapproxy-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapproxy-dev</a><br>
</blockquote></div></div>