1. Oliver Tonnhofer
  2. mapproxy
  3. Issues
Issue #40 resolved

Custom Vendor Parameters for WMS and Caches

adorsk
created an issue

Feature request:

Allow for custom vendor parameters (filters, map files, etc.) to be included in WMS and Cache requests.

For example, say I have a WMS service that takes additional filters e.g. "http://foo.com/myservice?REQUEST=GetMap&...MY_CUSTOM_FILTER=a_filter_definition"

If my cache service receives a request that includes the parameter 'MY_CUSTOM_FILTER', I would like it to include the parameter in the request to the source WMS.

GeoWebCache claims to support this: http://geowebcache.org/docs/current/quickstart/index.html

MapCache also claims to support this: http://www.mapserver.org/trunk/mapcache/index.html#features

Comments (9)

  1. adorsk reporter

    There is a case in which this would be useful: the case in which the source data is static, and the client wishes to dynamically select a subset of the data. The data itself would not change, so cached requests would be valid.

    For example, say I have a large sptial database of restaurants. I want to make a web interface for displaying the restaurants that allows me to filter the restaurants by rating, cuisine, etc. In this case requests would look something like:

    http://restaurants.foo.com/cache?REQUEST=GetMap...FILTERS=cuisine:chinese,indian;price=high,low....

    I would want to be able to pass the 'FILTERS' parameter on to my source WMS.

    In the meanwhile I'm going to use a generic caching solution (like Nginx or Squid). But it would be nice to have a way to take advantage of the tiling features in MapProxy.

    In general I'm very impressed by MapProxy and the documentation, nice work!

  2. Anonymous

    I agree that this will not work well with caching, but on the other hand, this could be really useful when no caching is required. For example that would allow using the time parameter of wms-t or any custom vendor params. I currently need to use mapproxy as wms-t authorization proxy only (no caching needed here) and leveraging you last devs on clipping: http://mapproxy.org/docs/nightly/auth.html#limited-to

    Concerning caching, we could properly document it so that the user knows that the caching does not take into account these extra parameters, and that caching should not be used if the vendor params changes the output.

    What do you think? Does it make sense to add some kind of wms vendor params support to mapproxy?

    I had a look to mapproxy code, and I don't see any easy way to implement that because mapproxy currently creates its own request for querying wms services without tracking the original request. One way to implement vendor params support would be to update "MapQuery" object so that it can contain some arbitrary vendor params, but I'm not sure this is the best approach. I would be happy to provide a patch but I would appreciate some guidance :-)

    Concerning the configuration, we could have a "forward_params" array in wms config in which we could choose which custom parameters should be forwarded. Something like:

    sources:                                                                                                                                                           
      mywms:
        type: wms
        req:
          url: http://url/to/wms
          forward_params: ['time']
    
  3. Oliver Tonnhofer repo owner

    Sounds good to me.

    MapQuery could take an optional ForwardParameters object as an argument. Sources can then decide if they use these parameters or not. Caches could filter these out if they don't support it. Maybe ForwardParameters should be called DimensionParameters, so that it can be reused when MapProxy supports to cache multiple dimensions...

    For the configuration: I think I would put the option outside of req, since MapProxy copies all options (except url) verbatim to the URL (e.g. map: foo becomes ...&map=foo).

    sources:                                                                                                                                                           
      mywms:
        type: wms
        forward_req_params: ['time']
        req:
          url: http://url/to/wms
    
  4. lrm

    Guys,

    As adorsk stated, this CAN work well with caching indeed. It depends on how would you use it.

    For example, we have a Mapserver source that uses MAPFILES that use custom parameters to get the same set of images. It's just a matter os passing parameters to the mapfile to get the correct set of images, but the images are static in the end.

    To use mapproxy as of now, with caching (because we cant use forward_req_params with caches), we would have to build a HUGE conf file with tons of sources, each pointing to the same Mapserver URL, just changing ONE parameter.

    If you make forward_req_params work for caches, you would make our lives a lot easier.

    Please reconsider that decision, forward_req_params should really work with caches aswell. Make the feature fully available, and let the users decide whats the best use case...

    Thanks a lot!

    Best,

  5. Oliver Tonnhofer repo owner
    For example, we have a Mapserver source that uses MAPFILES that use custom parameters to get the same set of images. It's just a matter os passing parameters to the mapfile to get the correct set of images, but the images are static in the end.
    

    If the image is the same, can't you just add your parameter to the WMS req option in the mapproxy.yaml?

    You need to create a unique cache for each parameter when the images differ (Adorsk wanted to use Squid/Nginx for that). This could be solved with the "dimension feature" that is not yet implemented.

    Please reconsider that decision, forward_req_params should really work with caches aswell. Make the feature fully available, and let the users decide whats the best use case...
    

    There is no decision made. Features need someone to implement it or someone to fund the implementation.

  6. Log in to comment