Improving WMS GetFeatureInfo - Part 1
This is a two-part post on how the GetFeatureInfo operation of Web Map Services (WMS) could be improved. Part one will explain why I think GetFeatureInfo needs improving. Part two will suggest a mandatory GetFeatureInfo response format (as a straw man).
This post has been rattling around my head since about October 2004. It is about time that I fleshed it out.
The GetFeatureInfo operation is optional in the WMS specification. The fact that its is optional is OK by me, but it always struck me as odd that there was no mandatory format for GetFeatureInfo responses.
Clicking on a map to ask “what’s this?” is very useful, so most WMS implementations do support GetFeatureInfo requests. The problem is that there is no mandatory format for GetFeatureInfo responses. The different WMS implementations provide their own GetFeatureInfo response formats. Some use HTML, some use XML, etc.
Interoperability in the WMS specification is based on well-known interfaces and well-known response message formats. When you send a GetMap or GetCapabilities request you know what the possible response message formats are. However, when you send a GetFeatureInfo request you don’t know what you’re going to get back.
To get around this problem developers of WMS client applications have to create GetFeatureInfo “adapters” for each WMS product. This creates a lot of development work just to create a seamless user experience. However, the more important issue is that the client application now needs to know which flavour of WMS it is conversing with. This goes against the idea of interoperability. One WMS implementation should be able to be swapped out for another WMS implementation without any of the client applications knowing the change has occurred.
Use Cases
In my experience there are three common actions a client application will take after receiving a GetFeatureInfo response:
- Display the properties of the queried feature(s) on screen.
- Redirect to an alternate representation of the queried feature(s). E.g. GML with geometry, HTML, etc.
- Redirect to a resource related to the queried feature(s). E.g. a report showing time series data, a HTML page describing data classes, etc.
One GetFeatureInfo response format could cater for all these requirements.
Note: Digital Earth Pty Ltd is not a member of the OpenGeospatial Consortium. Techncial Committee membership costs USD11k, and that’s not in the budget.
Go to Part 2 of this post.
[tags]WMS, interoperability, web services[/tags]
I think the chances of getting a change through on the ISO version of WMS are tough. But in the meantime, I would suggest defining a Vendor Specific Parameter that everyone who wants to do this sort of thing can agree on. Then once enough people have started using it you can show how well accepted and extensively used the feature is and perhaps get a change proposal into the process.
Allan Doyle — 4 January 2006, 18:00
Rhonda — 12 April 2006, 15:46