[MapProxy] Two GetFeatureInfo issues

Oliver Tonnhofer olt at omniscale.de
Fri Oct 8 07:32:31 EDT 2010


Hi Anne,

On 07.10.2010, at 13:41, Anne Blankert wrote:
> Sorry, you are right. I overlooked the <map_request_copy> parameter. The
> question remains if MapProxy or the WMS should complain about such
> missing parameters. The MapProxy 'non_strict: true' config setting (see
> below) relays the problem to the WMS, maybe this should be the default
> config?

Yes. I'm open to make MapProxy more "relaxed" by default. I'll change the behavior for 0.9 and make non_strict the default.

>>> Some things to note:
>>> 1. The MapProxy-to-WMS-server-request does not use the wmtver parameter
>>> (although MapProxy requires the client to provide it)
>>> 2. The bbox,width,height,x and y parameters were not transformed in the
>>> MapProxy-to-WMS-server-request. I verified that the current MapProxy
>>> configuration does transform GetMap requests. Is there a seperate
>>> 'supported_srs' parameter for GetFeatureInfo requests?
>> 
>> 1. WMTVER is 1.0.0 only, it sends the correct VERSION parameter.
> If you send a WMS version 1.1.0 (not 1.1.1) GetFeatureInfo request to
> MapProxy, then MapProxy complains that the required wmtver parameter is
> missing. According to
> http://portal.opengeospatial.org/files/?artifact_id=1058, the WMTVER
> parameter is deprecated for WMS 1.1.0.
> According to the comment in file 'mapproxy/wms/request.py' under
> function 'negotiate_version', version 1.1.0 is mapped to 1.0.0. If I am
> correct, this approximation fails for the VERSION/WMTVER parameter.
> Wouldn't a mapping of 1.1.0 to 1.1.1 be a better approximation?

The problem is, that a client should never issue a request in a version the server does not understand. The version negotiation should happen during the capabilities exchange and the spec defines that a server should respond with an older version, if the requested is not supported. So your client should have retrieved a 1.0.0 document and should send requests in that version. That's the theory, and thats how we implemented it :)

I'm not familiar with the exact differences between 1.1.0 and 1.1.1. Maybe it is ok to handle 1.1.0 requests as 1.1.1, but I need to check the spec at first.

BTW: Can you tell me which client you are using?

>> 2. Thats odd, it should transform the request. I can look into that, but I'm a bit busy this week (Intergeo).
> I tried some alternative configurations, but was not yet able to get
> GetFeatureInfo to transform the coordinates in the request. Ofcourse I'd
> be happy to mail my full services.yaml to reproduce my
> GetFeatureInfo-does-not-transform problem.

OK, I can reproduce it. The GetFeatureInfo transformation only checked the srs of the request parameters (i.e. an explicit srs, configured like layers, transparent, etc) and not the supported_srs list. I have updated the tests and fixed the issue.

There is a new package:
http://mapproxy.org/static/rel/MapProxy-0.8.6.dev-20101008.tar.gz

Thanks for reporting.

Regards,
Oliver

-- 
Oliver Tonnhofer <olt at omniscale.de>
Omniscale - Dominik Helle, Oliver Tonnhofer GbR
Nadorster Str. 60, 26123 Oldenburg
Tel: +49(0)441/9392774-2 (Fax: 9)



More information about the MapProxy mailing list