[MapProxy] Two GetFeatureInfo issues

[Anne Blankert]

 Hi,

My comments in between the lines below.

On 10/4/2010 1:02 PM, Oliver Tonnhofer wrote:
> Hi,
>
> On 04.10.2010, at 12:37, Anne Blankert wrote:
>>> We are still not sure how to handle these clients in general: Sniffing the user-agent would be a solution, or just ignoring the missing parameters.
>> There can be many user-agents, many of which may be custom user-agents,
>> unknown to MapProxy. Wouldn't it be a good idea that MapProxy only
>> requires those parameters that are needed for proxying and let the
>> remote server decide on the other parameters? If the remote server does
>> not like the request, the resulting exception can be proxied to the
>> MapProxy client. What would be the benefit of a proxy that is more
>> strict than the proxied service?
> Yes, that might be a good solution. I have to think about it.
>
>>>> If I am correct these parameters are not normally required for WMS GetFeatureInfo requests?
>>> The format, not so much, but the style can affect the request (e.g. x,y might hit a thick line, but not a thin line). Regardless of that, they are required by the spec.
>>>
>> What spec are you referring to? The spec at
>> http://portal.opengeospatial.org/files/?artifact_id=1081&version=1&format=pdf,
>> section 7.3.2, table 9, does not mention these parameters.
> Right there, <map_request_copy>:
> "Two are omitted because GetFeatureInfo provides its own values: VERSION and REQUEST. The remainder of the GetMap request shall be embedded contiguously in the GetFeatureInfo request."
>
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?

>> I've tried this option in several ways 'non_strict: True' and
>> 'wms.non_strict: True' in file proxy.yaml under 'param', and 'wms_opts'
>> but MapProxy keeps on telling me I should provide the remaining
>> parameters.
> Sorry, with wms.non_strict I meant non_strict parameter in the wms section. 
> In proxy.yaml:
>
>   wms:
>     non_strict: True
>
>
Now works great, thanks.
>> 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?

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

Regards,

Anne