[mapserver-dev] Re: ms rfc 71: mod-geocache integration

[Pavel Iacovlev]

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.
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.

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.

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?

On Wed, May 25, 2011 at 2:00 PM, thomas bonfort <thomas.bonfort at gmail.com>wrote:

> Pavel,
>
> see my upcoming answer to Steve Woodbridge concerning the mapfile
> parsing by mod-geocache.
>
> as for your concern regarding layers that are added dynamically by
> mapscript, I think this is a use case that is not covered by a tile
> caching solution. If your layers are added based on some parameters
> received by url, then mod-geocache can be told to buid a cache
> accordingly if you set those parameters as dimensions. But if they are
> set dynamically by mapscript based on some server-side configuration,
> then I'd say that that kind of layer is not a candidate to be cached.
>
> did I understand your question correctly?
>
> --
> thomas
>
> On Tue, May 24, 2011 at 11:50, Pavel Iacovlev <iacovlev.pavel at gmail.com>
> wrote:
> > Hi Thomas,
> > As I understand all configuration options will be kept in a single
> mapfile,
> > and the same mapfile will be parsed by mapserver and by mod-geocache ?
> Does
> > this mean that mod-geocache won't work with MapScript in the case when
> > layers/configuration options are added/removed dynamically ?
> > Also +1 for mod-geocache, it an awesome addition.
> > On Tue, May 24, 2011 at 11:21 AM, thomas bonfort <
> thomas.bonfort at gmail.com>
> > wrote:
> >>
> >> no comments?
> >>
> >> I would think that the proxying nature of mod-geocache integration
> >> needs discussion. The scenario is as follows:
> >>
> >> * user creates a mapfile that needs tilecaching support, placed at
> >> /path/to/mapfile.map. This mapfile contains some configuration
> >> keywords to declare what layers are to be cached, the definitions of
> >> the tile grids that will be used, where to store cached tiles, etc...
> >>
> >> * apache configuration is set like:
> >> <Location /mymapservice>
> >>  SetHandler geocache
> >>  GeocacheConfigFile /path/to/mapfile
> >> </Location>
> >>
> >> * user publishes the url to his service as http://myhost/mymapservice
> >> * incoming requests to /mymapservice are treated as follows:
> >>  * WMS requests that correspond to tile requests of a cached layer
> >> are intercepted by mod-geocache
> >>  * WMS requests that correspond to general getMap requests of a
> >> cached layer are treated by mod-geocache and are reconstructed by
> >> assembling cached tiles (or forwarded to mapserver if configured so)
> >>  * non wms tiled requests are treated by mod-geocache, on the urls
> >> http://myhost/mymapservice/(wmts|tms|kml|etc...)/
> >>  * all other requests (WMS on a grid with different SRID, WFS, WCS,
> >> etc...) are forwarded to http://localhost/cgi-bin/mapserv (or another
> >> server+path)?map=/path/to/mapfile&(forwarded incoming request params).
> >> With some configuration, the user can also configure specific requests
> >> to be forwarded to a specific url, eg WFS-T requests go to
> >> http://localhost/cgi-bin/tinyows.
> >>
> >> This scenario has the advantage that the mod-geocache configuration
> >> and operation is quite decoupled from the mapserver one, and allows
> >> the publication of a single entry point into *all* the services
> >> offered by /path/to/mapfile.map. It has two inconveniences:
> >>  * all non tiled requests are proxied, and therefore go through a
> >> second http request. This adds the overhead of mod-geocache parsing
> >> (which is minimal as it consists of checking the service is WMS, then
> >> that the requested layers are cached, that the SRS corresponds to the
> >> layer's tile grid, and optionally finally that the extent+size matches
> >> the configured tile grids), plus the overhead of a second http request
> >> (which should be minimal as it happens on localhost or the local
> >> network).
> >> * WMS GetCapabilities responses are generated by mapserver, and
> >> therefore would not contain the WMS-C extension indicating that
> >> there's a cache available. We could imagine that mod-geocache
> >> intercepts the mapserver-generated xml, and inserts the WMS-C vendor
> >> extension required to publicize the tiled service.
> >>
> >> --
> >> thomas
> >>
> >> On Fri, May 20, 2011 at 17:22, thomas bonfort <thomas.bonfort at gmail.com
> >
> >> wrote:
> >> > I've committed a draft version of rfc 71 here:
> >> >
> >> >
> http://trac.osgeo.org/mapserver/browser/trunk/docs/en/development/rfc/ms-rfc-71.txt
> >> >
> >> > awaiting your comments...
> >> >
> >> > --
> >> > thomas
> >> >
> >> _______________________________________________
> >> mapserver-dev mailing list
> >> mapserver-dev at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20110525/a85e4268/attachment.html