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

Mon Jun 6 12:57:37 EDT 2011

On Tue, May 31, 2011 at 16:07, Yewondwossen Assefa
<yassefa at dmsolutions.ca> wrote:
> 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?
Taking the wms(-c) capabilities creation out of mod-geocache and
forwarding them to mapserver makes a lot of sense. In that case, we
would have to adapt the code to account for the two points you
mention, i.e. have mod-geocache parse the mapfile to extract what
layers/groups are going to be cached (and under what name), and modify
the mapserver wms capabilities to produce the wms-c blurb.

As for the mapfile parsing by mod-geocache, it might be simpler to
have mod-geocache parse the mapserver wms-c capabilities at startup
and extract it's configuration from there... It would make things very
easy to configure in the basic use-case (i.e. a single cached layer,
with no support of dimensions). The more evolved use-cases would need
some extra thinking.

--
thomas

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