Ticket #2678 (closed feature: fixed)

Opened 3 years ago

Last modified 3 years ago

create WMTSGetFeatureInfo control

Reported by: tschaub Owned by: tschaub
Priority: minor Milestone: 2.10 Release
Component: Control Version: 2.9
Keywords: Cc:
State: Complete

Description

The WMTS spec allows for GetFeatureInfo requests.

Attachments

2678.patch Download (30.5 KB) - added by tschaub 3 years ago.
WMTSGetFeatureInfo control
openlayers-2678.patch Download (30.3 KB) - added by ahocevar 3 years ago.
2678.2.patch Download (33.2 KB) - added by tschaub 3 years ago.
WMTSGetFeatureInfo control

Change History

  Changed 3 years ago by tschaub

  • state set to Review

  Changed 3 years ago by tschaub

Depends on #2677.

  Changed 3 years ago by 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?

  Changed 3 years ago by tschaub

  • state changed from Review to Needs More Work

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.

follow-up: ↓ 6   Changed 3 years ago by bartvde

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

in reply to: ↑ 5   Changed 3 years ago by 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.

Changed 3 years ago by tschaub

WMTSGetFeatureInfo control

  Changed 3 years ago by tschaub

  • state changed from Needs More Work to Review

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.

  Changed 3 years ago by tschaub

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

  Changed 3 years ago by ahocevar

  • state changed from Review to Commit

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.

Changed 3 years ago by ahocevar

  Changed 3 years ago by tschaub

  • owner set to tschaub
  • status changed from new to assigned

Changed 3 years ago by tschaub

WMTSGetFeatureInfo control

  Changed 3 years ago by 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.

  Changed 3 years ago by 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.

  Changed 3 years ago by tschaub

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

  Changed 3 years ago by tschaub

  • status changed from assigned to closed
  • state changed from Commit to Complete
  • resolution set to fixed

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

Note: See TracTickets for help on using tickets.