create WMTSGetFeatureInfo control

[tschaub]

The WMTS spec allows for GetFeatureInfo requests.

[tschaub]

Depends on #2677.

[bartvde]

Hey Tim, a question, is there a way we could reuse the WMSGetFeatureInfo control to work also on WMTS layers? Can you elaborate why you did not choose that approach?

[tschaub]

Yeah, I needed to deliver something last week and there are significant differences between the two controls. Given some more work, the existing control could be hacked to support WMTS GetFeatureInfo requests. It would start getting a bit awkward to support the "RESTful" encoding for WMTS with the existing control (mixed with query string encoding for WMS layers).

No need to review this closely now, as #2677 needs more work.

[bartvde]

Thanks for the clarification Tim, I wonder if for 3.0 we could create protocols for GetFeatureInfo?

[elemoine]

Replying to bartvde:

Thanks for the clarification Tim, I wonder if for 3.0 we could create protocols for GetFeatureInfo?

Protocol.WMS and Protocol.WMTS, supporting read only, would make sense to me.

[tschaub]

WMTSGetFeatureInfo control

[tschaub]

Regarding the existing WMSGetFeatureInfo control, this control is implemented separately because of the significant ways that the two specs define the operation. Though I mentioned that "with more work" the two could be merged, I think this would end up in a mess. If someone really wanted a generic "feature info" control, they could put one together that created separate obligate controls based on the different layer types. In general, it confuses things when you treat a cache like a full fledged WMS - and I think separating these controls is appropriate.

[tschaub]

Now that #2677 is ready for review, this one is too.

[ahocevar]

Given the different nature of WMTSGetFeatureInfo and WMSGetFeatureInfo, we should make some changes to make this more straightforward:

• WMTS GetFeatureInfo does not support multiple layers in one request, so the drillDown option is pretty much useless -- it would just mean to only request GetFeatureInfo for one layer. I propose to remove it, just like url.
• Without drillDown, we save some code, but we have to make sure that we return something useful with the getfeatureinfo event. So I suggest replacing the request property of the event object with requests, an array of all issued requests. For better support of infoFormats that do not return parseable features, I propose to add a parseText function which concatenates the responseText of each request. This function can be customized by the application developer. The advantage is that the text property will always contain something that the application developer can use, regardless of the number of requests that had to be sent.

I can think of another improvement:

• We do not need to configure the control with a format if we use an infoFormat like "text/html". If format is optional and has no default, we also do not need formatOptions.

I am attaching a new patch with these changes and modified/additional tests. The example is also modified. Tests still pass. Please commit if you agree with my changes.

[tschaub]

WMTSGetFeatureInfo control

[tschaub]

The latest patch works well I think. The beforegetfeatureinfo and getfeatureinfo events are fired once for each layer queried. If a listener returns false for beforegetfeatureinfo, the layer is not queried. If the request or parsing fails, an exception event is fired. All events come with a reference to the layer queried.

The example works and tests pass on FF 3, Chrome 5, and IE 6. Thanks again for any review.

[ahocevar]

Thanks for the continued work on this Tim. This looks really good now. Only one minor thing in the tests: there is a typo. The test message says "two requests issued" twice, but it should say "one request issued" one time, and "three requests issued" the other.

Please commit.

[tschaub]

Thanks for the careful review(s). I've updated the assertion messages.

[tschaub]

(In [10656]) Adding a WMTSGetFeatureInfo control for querying WMTS layers. r=ahocevar (closes #2678)