<div dir="ltr">Steve,<div><br></div><div>Thanks for the detailed explanation. Sounds like a very logical solution. MapServer is so powerful in its ability to both consume and serv WMS.</div><div><br></div><div>The thread caught my eye because my apps typically have a few dozen layers that users can turn on/off in any combination, which makes caching less practical.</div><div><br></div><div>Best regards,</div><div>Rich</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 5, 2019 at 8:49 PM Stephen Woodbridge <<a href="mailto:stephenwoodbridge37@gmail.com">stephenwoodbridge37@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">On 2/5/2019 8:52 PM, Richard Greenwood wrote:<br>
> Stephen,<br>
><br>
> I was watching this thread hoping for a reply to your original <br>
> question because it's an interesting problem. If you have time to <br>
> provide a more detailed explanation of your solution I'd be interested.<br>
<br>
So what I had originally were 7 layers of NOAA ENC (Electronic Nautical <br>
Charts) being pulled from the NOAA WMS service and these were getting <br>
cached locally in mapcache. Since my app was always turning on/off all <br>
seven layers as a set, I wanted to build a new layer that merged all <br>
seven into a single layer. Part of the reason for this was to reduce the <br>
number of layer in openlayers for performance improvements. This would <br>
be just a vertical stacking of the the seven layers into one. Because of <br>
the way NOAA service is structured each layer has a different end point <br>
so it was not possible to have their server do the stacking.<br>
<br>
I eventually found this post:<br>
<a href="https://lists.osgeo.org/pipermail/mapserver-users/2012-April/072045.html" rel="noreferrer" target="_blank">https://lists.osgeo.org/pipermail/mapserver-users/2012-April/072045.html</a><br>
which suggests, this might no be the best approach.<br>
<br>
In addition, while looking at this issue I realized the NOAA service <br>
changed it layer definitions for some of the data and my mapcache stuff <br>
was broken as a result. In the end, I decided to create a mapserver <br>
mapfile that did WMS client requests to the NOAA server and broke up the <br>
seven layers into 21 (7 each area, line and point) smaller layers that <br>
allowed for more correct stacking of the data and setting appropriate <br>
MIN/MAX scaledenom  values as recommended by the getCapabilities for the <br>
NOAA services. Now I have one mapcache layer that uses the new mosaic <br>
mapfile and this does the vertical stacking which is slow given that <br>
mapserver has to make about 21 WMS requests to serve each metatile <br>
request from mapcache. But the end result is good and tiles are fast <br>
once they are populated.<br>
<br>
Also, I will note that the NOAA ENC service updates the chart data on a <br>
regular basis, so I expire my tiles in the cache after 7 days so they <br>
get regenerated possible using new data. I think because of this, the <br>
strategy of using mapserver to do the stacking and mapcache to handle <br>
the caching is a better division of labor and once the app is converted <br>
to use the new mosaic layer, I'll remove the 7 old layers to free up <br>
disk space.<br>
<br>
Hope this helps someone with a similar issue.<br>
<br>
Best regards,<br>
   -Steve W<br>
<br>
><br>
> Best regards,<br>
> Rich<br>
><br>
><br>
> On Tue, Feb 5, 2019 at 4:38 PM Stephen Woodbridge <br>
> <<a href="mailto:stephenwoodbridge37@gmail.com" target="_blank">stephenwoodbridge37@gmail.com</a> <mailto:<a href="mailto:stephenwoodbridge37@gmail.com" target="_blank">stephenwoodbridge37@gmail.com</a>>> <br>
> wrote:<br>
><br>
>     I found response to question by Thomas on this subject that<br>
>     suggested it might cause a deadlock if you ran out of connections.<br>
><br>
>     Anyway I decided to build a new map file to do the vertical<br>
>     assembly and then cache that through mapcache.<br>
><br>
>     -Steve<br>
><br>
>     Sent from my iPhone<br>
><br>
>     On Jan 27, 2019, at 11:35 PM, Lime, Steve D (MNIT)<br>
>     <<a href="mailto:steve.lime@state.mn.us" target="_blank">steve.lime@state.mn.us</a> <mailto:<a href="mailto:steve.lime@state.mn.us" target="_blank">steve.lime@state.mn.us</a>>> wrote:<br>
><br>
>>     I’ll try to derive something from the source and report back.<br>
>>     ------------------------------------------------------------------------<br>
>>     *From:* mapserver-users <<a href="mailto:mapserver-users-bounces@lists.osgeo.org" target="_blank">mapserver-users-bounces@lists.osgeo.org</a><br>
>>     <mailto:<a href="mailto:mapserver-users-bounces@lists.osgeo.org" target="_blank">mapserver-users-bounces@lists.osgeo.org</a>>> on behalf of<br>
>>     Stephen Woodbridge <<a href="mailto:stephenwoodbridge37@gmail.com" target="_blank">stephenwoodbridge37@gmail.com</a><br>
>>     <mailto:<a href="mailto:stephenwoodbridge37@gmail.com" target="_blank">stephenwoodbridge37@gmail.com</a>>><br>
>>     *Sent:* Sunday, January 27, 2019 7:08:38 PM<br>
>>     *To:* mapserver-users<br>
>>     *Subject:* [mapserver-users] mamcache vertical assembly<br>
>>     Hi,<br>
>><br>
>>     The mapcache docs has a page for vertical assembly but it is blank :(<br>
>><br>
>>     I have 7 layers in mapcache and I would like to vertically assemble<br>
>>     these into a composite layer. In the past I have been loading all<br>
>>     7 in<br>
>>     openlayers but it makes more sense to just composite them into a new<br>
>>     layer. There are some scale limits that apply to the various layers.<br>
>><br>
>>     Does anyone have some info on how to do this in mapcache directly<br>
>>     rather<br>
>>     than create a mapfile and compositing them in mapserver and then<br>
>>     making<br>
>>     that a new layer in mapcache.<br>
>><br>
>>     Thanks,<br>
>>        -Steve W<br>
>><br>
>>     ---<br>
>>     This email has been checked for viruses by Avast antivirus software.<br>
>>     <a href="https://www.avast.com/antivirus" rel="noreferrer" target="_blank">https://www.avast.com/antivirus</a><br>
>><br>
>>     _______________________________________________<br>
>>     mapserver-users mailing list<br>
>>     <a href="mailto:mapserver-users@lists.osgeo.org" target="_blank">mapserver-users@lists.osgeo.org</a><br>
>>     <mailto:<a href="mailto:mapserver-users@lists.osgeo.org" target="_blank">mapserver-users@lists.osgeo.org</a>><br>
>>     <a href="https://lists.osgeo.org/mailman/listinfo/mapserver-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-users</a><br>
>     _______________________________________________<br>
>     mapserver-users mailing list<br>
>     <a href="mailto:mapserver-users@lists.osgeo.org" target="_blank">mapserver-users@lists.osgeo.org</a><br>
>     <mailto:<a href="mailto:mapserver-users@lists.osgeo.org" target="_blank">mapserver-users@lists.osgeo.org</a>><br>
>     <a href="https://lists.osgeo.org/mailman/listinfo/mapserver-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-users</a><br>
><br>
><br>
><br>
> -- <br>
> Richard W. Greenwood, PLS<br>
> <a href="http://www.greenwoodmap.com" rel="noreferrer" target="_blank">www.greenwoodmap.com</a> <<a href="http://www.greenwoodmap.com" rel="noreferrer" target="_blank">http://www.greenwoodmap.com</a>><br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Richard W. Greenwood, PLS<br><a href="http://www.greenwoodmap.com" target="_blank">www.greenwoodmap.com</a></div></div>