<meta http-equiv="content-type" content="text/html; charset=utf-8">In my case there is "no mapfile" everything is constructed via PHP, layer options are pulled from the database, also authentication is done in PHP. <div>
At the moment the work flow is if you request WMS/WFS PHPMapscript serves it. If you request tiles (different url) tilecache handles it (with it's own rules in tilecache.cfg) and if no tile is found it get redirected to PHPMapscript.<br>
<br></div><div>Now I want to move to mod-geocache, so in my case I have to specify a mapfile, because I don't have one cuz mine is created on the fly. Now as I think about it more, I can define additional options for mod-geocache (if/when they be available for MapScript) and export the mapObj to .map so mod-geocache can use it, but it seems an overkill. In my opinion dedicated config file for mod-geocache (as it is now) is a more cleaner solution.</div>
<div><br></div><div>Also a question about the config file, does it check on every request if the file is changed ? and if yes update the configuration, or I need an apache reload/restart for the chnages to take place?</div>
<div><br></div><div class="gmail_quote">On Wed, May 25, 2011 at 2:00 PM, thomas bonfort <span dir="ltr"><<a href="mailto:thomas.bonfort@gmail.com">thomas.bonfort@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Pavel,<br>
<br>
see my upcoming answer to Steve Woodbridge concerning the mapfile<br>
parsing by mod-geocache.<br>
<br>
as for your concern regarding layers that are added dynamically by<br>
mapscript, I think this is a use case that is not covered by a tile<br>
caching solution. If your layers are added based on some parameters<br>
received by url, then mod-geocache can be told to buid a cache<br>
accordingly if you set those parameters as dimensions. But if they are<br>
set dynamically by mapscript based on some server-side configuration,<br>
then I'd say that that kind of layer is not a candidate to be cached.<br>
<br>
did I understand your question correctly?<br>
<br>
--<br>
<font color="#888888">thomas<br>
</font><div><div></div><div class="h5"><br>
On Tue, May 24, 2011 at 11:50, Pavel Iacovlev <<a href="mailto:iacovlev.pavel@gmail.com">iacovlev.pavel@gmail.com</a>> wrote:<br>
> Hi Thomas,<br>
> As I understand all configuration options will be kept in a single mapfile,<br>
> and the same mapfile will be parsed by mapserver and by mod-geocache ? Does<br>
> this mean that mod-geocache won't work with MapScript in the case when<br>
> layers/configuration options are added/removed dynamically ?<br>
> Also +1 for mod-geocache, it an awesome addition.<br>
> On Tue, May 24, 2011 at 11:21 AM, thomas bonfort <<a href="mailto:thomas.bonfort@gmail.com">thomas.bonfort@gmail.com</a>><br>
> wrote:<br>
>><br>
>> no comments?<br>
>><br>
>> I would think that the proxying nature of mod-geocache integration<br>
>> needs discussion. The scenario is as follows:<br>
>><br>
>> * user creates a mapfile that needs tilecaching support, placed at<br>
>> /path/to/mapfile.map. This mapfile contains some configuration<br>
>> keywords to declare what layers are to be cached, the definitions of<br>
>> the tile grids that will be used, where to store cached tiles, etc...<br>
>><br>
>> * apache configuration is set like:<br>
>> <Location /mymapservice><br>
>> SetHandler geocache<br>
>> GeocacheConfigFile /path/to/mapfile<br>
>> </Location><br>
>><br>
>> * user publishes the url to his service as <a href="http://myhost/mymapservice" target="_blank">http://myhost/mymapservice</a><br>
>> * incoming requests to /mymapservice are treated as follows:<br>
>> * WMS requests that correspond to tile requests of a cached layer<br>
>> are intercepted by mod-geocache<br>
>> * WMS requests that correspond to general getMap requests of a<br>
>> cached layer are treated by mod-geocache and are reconstructed by<br>
>> assembling cached tiles (or forwarded to mapserver if configured so)<br>
>> * non wms tiled requests are treated by mod-geocache, on the urls<br>
>> <a href="http://myhost/mymapservice/(wmts|tms|kml|etc...)/" target="_blank">http://myhost/mymapservice/(wmts|tms|kml|etc...)/</a><br>
>> * all other requests (WMS on a grid with different SRID, WFS, WCS,<br>
>> etc...) are forwarded to <a href="http://localhost/cgi-bin/mapserv" target="_blank">http://localhost/cgi-bin/mapserv</a> (or another<br>
>> server+path)?map=/path/to/mapfile&(forwarded incoming request params).<br>
>> With some configuration, the user can also configure specific requests<br>
>> to be forwarded to a specific url, eg WFS-T requests go to<br>
>> <a href="http://localhost/cgi-bin/tinyows" target="_blank">http://localhost/cgi-bin/tinyows</a>.<br>
>><br>
>> This scenario has the advantage that the mod-geocache configuration<br>
>> and operation is quite decoupled from the mapserver one, and allows<br>
>> the publication of a single entry point into *all* the services<br>
>> offered by /path/to/mapfile.map. It has two inconveniences:<br>
>> * all non tiled requests are proxied, and therefore go through a<br>
>> second http request. This adds the overhead of mod-geocache parsing<br>
>> (which is minimal as it consists of checking the service is WMS, then<br>
>> that the requested layers are cached, that the SRS corresponds to the<br>
>> layer's tile grid, and optionally finally that the extent+size matches<br>
>> the configured tile grids), plus the overhead of a second http request<br>
>> (which should be minimal as it happens on localhost or the local<br>
>> network).<br>
>> * WMS GetCapabilities responses are generated by mapserver, and<br>
>> therefore would not contain the WMS-C extension indicating that<br>
>> there's a cache available. We could imagine that mod-geocache<br>
>> intercepts the mapserver-generated xml, and inserts the WMS-C vendor<br>
>> extension required to publicize the tiled service.<br>
>><br>
>> --<br>
>> thomas<br>
>><br>
>> On Fri, May 20, 2011 at 17:22, thomas bonfort <<a href="mailto:thomas.bonfort@gmail.com">thomas.bonfort@gmail.com</a>><br>
>> wrote:<br>
>> > I've committed a draft version of rfc 71 here:<br>
>> ><br>
>> > <a href="http://trac.osgeo.org/mapserver/browser/trunk/docs/en/development/rfc/ms-rfc-71.txt" target="_blank">http://trac.osgeo.org/mapserver/browser/trunk/docs/en/development/rfc/ms-rfc-71.txt</a><br>
>> ><br>
>> > awaiting your comments...<br>
>> ><br>
>> > --<br>
>> > thomas<br>
>> ><br>
>> _______________________________________________<br>
>> mapserver-dev mailing list<br>
>> <a href="mailto:mapserver-dev@lists.osgeo.org">mapserver-dev@lists.osgeo.org</a><br>
>> <a href="http://lists.osgeo.org/mailman/listinfo/mapserver-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/mapserver-dev</a><br>
><br>
><br>
</div></div></blockquote></div><br>