<div dir="ltr"><div>Dear Mapproxy community,</div><div><br></div><div>As Daniel indicated on the original message, we are sharing a request for comments (RFC) document for the work on implementing caching for WMS Dimensions in Mapproxy:</div><div><br></div><div><a href="https://gist.github.com/ingenieroariel/847d343ee7c5e1a7143234052ba2772d">https://gist.github.com/ingenieroariel/847d343ee7c5e1a7143234052ba2772d</a></div><div><br></div><div>We look forward to your input and will be refining the document as we learn more about the challenges and opportunities to get at least basic support in core mapproxy for this feature that is very important for Meteo agencies.</div><div><br></div><div>Thanks again Trond for offering to help, it will be very valuable to learn more about your current usage (in particular seeding scripts and any further modifications) and from other Mapproxy developers it will be helpful to know of potential pitfalls to avoid.</div><div><br></div><div>Best regards,</div><div>Ariel.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 4, 2020 at 1:34 PM Ariel Nunez <<a href="mailto:ingenieroariel@gmail.com">ingenieroariel@gmail.com</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 dir="ltr"><pre>Dear Trond,<br><br></pre><pre>Thanks a lot for the PR you created and the offer to help.<br><br>I have started working locally on some modifications to it but I am still in time to adjust the approach.<br><br></pre><pre>Since this will need to go into production relatively soon I would be very interested in learning more about your preseeding strategy and how you and the rest of the community consider this should ultimately work.<br><br></pre><pre>I'll follow up with you off list and then post an update here once we have a design document.<br><br></pre><pre>Best,<br></pre><pre>-Ariel<br></pre><pre><br>Hi.

That's great to hear. I'm the author of the pull request you mention,
and I'd be happy to assist in getting it to work. Since I made this
pull request, I have added dimension support to mbtiles caches, too.

I work at the Norwegian Meteorological Institute, and we have a
project coming up (in cooperation with two other Meteorological
Institutes) where we'll probably use Mapproxy, so we are also eager to
expand the support for dimensions. 

We are currently using mbtiles for our air quality forecast. Five
layers, 50 timesteps. The entire cache is preseeded (not by mapproxy)
every six hours.

<a href="https://luftkvalitet.miljostatus.no/kart/59.92/10.70/11/o3_concentration" target="_blank">https://luftkvalitet.miljostatus.no/kart/59.92/10.70/11/o3_concentration</a>


Anyway - this works pretty well, but I've not made any effort to
support preseeding or cache expiry.

If I were to start over, I think I'd rather subclass the Tile class,
and add a dimension attribute to it. That would probably be a lot more
elegant than my current patch. 


-- 
Trond Michelsen


On Thu, Feb 27, 2020 at 10:42:29AM -0500, Daniel Morissette wrote:
><i> Hello MapProxy devs and community,
</i>><i> 
</i>><i> This email is a heads up that we have started to work on the
</i>><i> implementation of WMS TIME dimension support in MapProxy, including
</i>><i> caching and seeding of time-enabled WMS sources, and support for
</i>><i> assembling WMS requests from a time-enabled tile cache.
</i>><i> 
</i>><i> This work is funded by the Meteorological Service of Canada and will
</i>><i> be used to serve hundreds or time-enabled weather layers, A RFC
</i>><i> (Request For Comments) document is underway and will be shared via
</i>><i> this list soon, so that other devs and contributors can comment on
</i>><i> the proposed approach to ensure that the implementation will meet
</i>><i> the expectations of the project to be included in future releases.
</i>><i> (We are also aware of <a href="https://github.com/mapproxy/mapproxy/pull/377" target="_blank">https://github.com/mapproxy/mapproxy/pull/377</a>
</i>><i> and will actually try to build on it)
</i>><i> 
</i>><i> A parallel goal of our initiative will be to set the bases to make
</i>><i> it easier for new devs to join the project as contributors and to
</i>><i> assist Oliver to maintain the project in the long run, inspired by
</i>><i> the way other OSGeo projects work. (We had some exchanges with
</i>><i> Oliver on this offlist already)
</i>><i> 
</i>><i> Finally, I am only the project lead here, the guys doing the bulk of
</i>><i> the coding work are:
</i>><i> 
</i>><i> - Ariel Nunez (<a href="https://github.com/ingenieroariel" target="_blank">https://github.com/ingenieroariel</a>)
</i>><i> - Denis Rykov (<a href="https://github.com/drnextgis" target="_blank">https://github.com/drnextgis</a>)
</i>><i> - Tom Kralidis (<a href="https://github.com/tomkralidis" target="_blank">https://github.com/tomkralidis</a>) - Tom is also the
</i>><i> end client who will be testing/validating the final results.
</i>><i> 
</i>><i> We should hear from them soon.
</i>><i> 
</i>><i> Cheers all
</i>><i> 
</i>><i> Daniel
</i>><i> -- 
</i>><i> Daniel Morissette
</i>><i> Mapgears Inc
</i>><i> 
</i>><i> _______________________________________________
</i>><i> MapProxy mailing list
</i>><i> <a href="https://lists.osgeo.org/mailman/listinfo/mapproxy" target="_blank">MapProxy at lists.osgeo.org</a>
</i>><i> <a href="https://lists.osgeo.org/mailman/listinfo/mapproxy" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapproxy</a>
</i></pre></div>
</blockquote></div>