Improving WMS GetFeatureInfo - Generic Features
Rhonda left a comment on my Improving WMS GetFeatureInfo – Part 2 post. In my effort to clarify my thoughts my responding comment got lengthy, so here’s a new post.
“GetFeatureInfo is not different than using the info tool in your favorite GIS client.”
Exactly! That’s what I’m trying to encourage with WMS. A WMS client should be able to display the GetFeatureInfo response using the same presentation style regardless of WMS implementation that provides the layer that was queried. All the GIS applications that I’ve used display a table of name/value pairs.
| ID | 1234 |
| Depth | 30.0 m |
The INFO_FORMAT parameter is mandatory, but by specifying INFO_FORMAT=text/xml& in your GetFeatureInfo request you still do not know what the content model of the XML response will be. In the current WMS specifications it is left to the WMS implementor. Therefore, a WMS client cannot provide a consistent and useful user experience.
I’m using the term “generic features” to describe the use of the element name Feature which contains Properties in the form of a set of Property title/value pairs. e.g.
[xml]
[/xml]
In contrast, the non-generic “feature typed” version would use meaningful element names. One possible example is:
[xml]
[/xml]
The generic feature approach can be used to describe details about any feature using one content model. This enables interoperability, and interoperability leads to a consistent experience for the user regardless of the WMS implementation.
In contrast, a GetFeatureInfo response that contains non-generic features requires prior knowledge of that specific content model. Unless a WMS client understands the semantics of my water bore schema it cannot render a visually consistent response for the user just by asking my WMS for INFO_FORMAT=text/xml&.
I understand that the format I am proposing is not good XML markup, from a semantic viewpoint, and that it results in tighter coupling. However, my position is that without an agreed GetFeatureInfo response format interoperability cannot occur without a lot of up front complexity.
Rhonda — 13 April 2006, 16:53
Smart people wrote the WMS specifications. They left the GetFeatureInfo response up to the implementor. You're saying the same. I feel like I'm missing something important here, but I have not seen an explanation as to why this is a good thing.
Can anyone educate me?
WMS would not interoperate if it was up to the implementor to determine what the content of the GetMap and GetCapabilities responses are. Why is GetFeatureInfo different?
Regarding joining the WMS Revision Working Group, I would be most interested, but if it requires Technical Committee membership, or even Associate Membership, that's well outside the budget of this small Australian company.
Andrew
Andrew Hallam — 13 April 2006, 17:57
The best example for why this is needed is for service chaining. Assuming you have 10 local layers and 3 pointing to remote services, trying to implement getFeatureInfo to cover the possible format response is almost impossible.
I had actually logged a bug on mapserver (http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1617) before i had actually looked more closely at the problem. Daniel summed it up pretty nicely in his response
"Unfortunately there is no defined format for a GetFeatureInfo response and until this is fixed in the spec (if it's ever fixed) there is no way that MapServer can ingest a GetFeatureInfo response from a remote server and do something meaningful with it (in order to cascade it)"
Geoserver also suffers from the same problem.
I would love to hear from Rhonda on how, in this environment, you could _easily_ implement this getFeatureInfo "brokering" when the format could differ wildly.
Granted, service chaining is just a bonus of the WMS spec, but this is a good example of why interoperable featureinfo's would be a very nice thing :)
Chris Tweedie — 13 April 2006, 19:05
Thanks, I'd forgotten about the cascading WMS issue. Very good point.
Just to be clear, I'm not suggesting that WMS implementations be limited to the GetFeatureInfo response that I have proposed. What I have proposed is functional, but it could also be the lowest common denominator fallback option.
Andrew
Andrew Hallam — 15 April 2006, 19:17