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

Tue May 31 10:07:11 EDT 2011

Hi,

Sorry for the delay.

  Reading this thread, I tend to also agree that It makes it hard to see 
a big advantage of having the configurations info being read from map 
file vs the config file used by mod-geocache. Most of the things in the 
config file are really independent from a specific map file and  apply 
to the configuration of the tile service, so having them in a map file 
might not really make sense.
What might be useful from a users perspective is to be able to easily 
say "make this layer/group of layers available through mod-geocache" 
and  have that  functionality available through settings in the map 
file.  Would it make sense to have to have mod-geocache parse mapfiles 
only for this kind of functionality and make the tile-sets available?
  Regarding the capabilities generation, would it make for MapServer to 
generate correct wms-c, onlineresource, ... elements if configured 
properly through metadata in the map file?

best regards,

Assefa

On 25/05/2011 7:25 AM, thomas bonfort wrote:
> Steve,
>
> Based on the recent evolutions concerning proxying that were added to
> mod-geocache, I was thinking along the same lines you were.
>
> Sharing the mapserver mapfile as a configuration file had the primary
> advantage that mod-geocache had access to the same metadata
> information for generating the WMS getcapabilities response. With the
> proxying support now available, I'm more and more inclined to not let
> mod-geocache create the capabilities response, and let it proxy it to
> mapserver: mod-geocache would do what it does best, i.e. just serve
> tiles, not become a full wms server on its own.
>
> This would have the primary advantages of not having to maintain
> capabilities creation in mod-geocache, and keep it available as a tile
> server in front of non-mapserver sources.
>
> I see some drawbacks with the solution however:
>
> - tiles are seen as a single WMS layer for mod-geocache, but can be
> mapped to multiple WMS layers in mapserver (eg: mod-geocache layer
> "mytileset" corresponds to mapserver layers
> "basemap,roads,buildings"). This could be overcome if the layers in
> the mapfile are configured with a GROUP that corresponds to the
> tileset name, i.e. GROUP mytileset. Another rather hacky solution
> would be to call the mod-geocache layer "basemap,roads,buidlings".
>
> - The capabilities created by mapserver and proxied by mod-geocache
> are not aware that there is a cache in front of the service. As such
> the onlineresources would probably be wrong, and there would not be
> the WMS-C vendorcapabilities added advertising the cached layers. With
> some further development effort, mod-geocache could be extended to
> parse the returned xml capabilities to correct the onlineresources and
> add the wms-c blurb. I'm personally not a very big fan of WMS-C as it
> is missing some major functionality to make it usefull in all but the
> trivial cases (i.e. no support for multiple grids/srs per layer, and
> no support for dimensions)
>
> regards,
>
> thomas
>
> On Wed, May 25, 2011 at 06:15, Stephen Woodbridge
> <woodbri at swoodbridge.com>  wrote:
>> Hi Thomas,
>>
>> Sorry for not responding earlier, I have been traveling and not had access.
>>
>> I think the one of the high value features of mod_geocache, is the fact that
>> it is easy to setup and works with any WMS source providers. Another high
>> value feature is that this uses proxy pattern which makes it high useful and
>> can stand on its own.
>>
>> So, I concerned about what value add we get from say having it read a
>> mapserver mapfile versus a mod_geocache config file. If I'm so non-mapserver
>> WMS source to work with mod_geocache, why would I want to create a mapserver
>> mapfile?
>>
>> In addition, I see publishing tiles more as an end point that is relatively
>> static so I would not think that the mapfile would be changing dramatically
>> so the tighter integration of directly reading the mapfile seems to be a
>> limited value, but maybe this is just a factor of my normal use cases and
>> other might have differing needs.
>>
>> I think there is good value in integrating the governance of mod_geocache,
>> and possibly optionally allowing the mod_geocache config file parser being
>> able to reference a mapfile to get its information, but it should not be
>> required for projects if they want to use mod_geocache.
>>
>> You and I had discussed adding security in the past and after thinking about
>> this some more, I have this idea stuck in my head that we should implement
>> this via something like a cascading proxy servers so we can keep each proxy
>> clean and focused. So something like:
>>
>> WMS request--->[ACL security proxy]---->[mode_geocache]--->[WMS server]
>>
>> This same model could be adapted to tinyows if the ACL security proxy was
>> extended to parse and validate WFS-T requests. Maybe the GeoPrisma team has
>> more input on the security side of things.
>>
>> -Steve W
>>
>> On 5/24/2011 5:26 AM, thomas bonfort wrote:
>>> On Tue, May 24, 2011 at 11:20, Olivier Courtin
>>> <olivier.courtin at oslandia.com>    wrote:
>>>> On May 24, 2011, at 10:21 AM, thomas bonfort wrote:
>>>>
>>>> Hi Thomas,
>>>>
>>>>> 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 use case also handle POST datas sended ?
>>> good point. mod-geocache currently does not support POST, and this
>>> should be added.
>>>
>>>> Could we imagine to enhance these proxy, in future, to add security
>>>> filtering
>>>> (auth, ACL check...) ?
>>> mod-geocache does not support those. I'm not sure if that would be its
>>> role or if that should be dedicated to another module kicking in
>>> before.
>>>
>>>> --
>>>> Olivier
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> mapserver-dev mailing list
>>>> mapserver-dev at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>>>
>>> _______________________________________________
>>> mapserver-dev mailing list
>>> mapserver-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>

-- 
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst

Email: yassefa at dmsolutions.ca
http://www.dmsolutions.ca/

Phone: (613) 565-5056 (ext 14)
Fax:   (613) 565-0925
----------------------------------------------------------------