parse relevant parameters from WMS layer url

[tschaub]

Some WMS capability responses include "service" parameters in their GetMap online resource href (see the response from  http://tinyurl.com/v6y9h). Unfortunately, this server is not clever enough to respond well when OL tacks on its own "SERVICE" parameter. (Sending both "service" and "SERVICE" doesn't work -  http://tinyurl.com/un2nz - while just sending one is fine -  http://tinyurl.com/yx4akt .)

This is easy to solve if the WMS layer url is parsed for relevant parameters when the layer is constructed. It would be especially easy if the patch for #378 were committed.

I'll hold off on creating a patch for this until others confirm that it makes sense.

(This is part of an effort to make OL work well with a WMS capabilities parser.)

[ctweedie]

Tim, your description sounds fine so long as you test explicitly for particular parameters (service,version,request) etc. while not stripping out important ones. Even though most onlineresources are "clean" enough, as you mentioned the following usecases you should make allowances for ... (some are obvious)

1. ArcIMS v4/9 WMS services typically have an additional "ServiceName" KVP to define the ArcIMS service.

2. UMN Mapserver by default attaches the "Map" KVP

3. Geoserver, from memory, will attempt to detect its port its running on and dump it to the onlineresource. I've had the same problem you mentioned regarding servers attaching :80 to the string

4. Demis' Web Map Server has a "WMS" KVP to define individual services

If it caters for those 4 you would have stiched up most servers :)

[tschaub]

Yes, thanks for the comments, I agree. Perhaps it would have been clearer to say that I propose to change Layer.WMS.initialize so that it parses the url for any DEFAULT_PARAMS before applying the defaults.

The one issue remaining is one of precedence. I propose that the order be parameters in the url, parameters in the params argument, and finally parameters in DEFAULT_PARAMS.

[tschaub]

patch to respect url search string parameters

[tschaub]

ok, this fix looks like it belongs in HTTPRequest.js

this patch requires the patch to #378 and incorporates the patch for #382 (both this patch and the patch for 382 are based on r1740)

please review

[crschmidt]

Reviewed, added a test, committed in r1907.