[wms-dev] Suggestion for Common GetFeatureInfo Response Format

[Andrew Hallam]

Keith Pomakis wrote:
> At the risk of complicating things, though, may I suggest BXFS as
> another alternative?

BXFS looks interesting, and is definitely a viable alternative. It seems
to cover everything in my suggestion, except for the "link" element
(more on that below) and units of measure in the property values. It is
a little more complex than what I was looking for in a GetFeatureInfo
response format. e.g. I was thinking RSS instead of SOAP - "Really
Simple GetFeatureInfo".

My goal was to provide a simple way to answer the "what's this?"
question when a user queries a map. The content should be very easy to
present to the end user. Providing discrete values that can be torn
apart by DOM/SAX code is lower priority. Stuff that's in my head:

1. Ignoring the present situation, each WMS client application 
should require only one XSL stylesheet to consistently render 
the GetFeatureInfo responses from any WMS instance. i.e. Not 
one XSL stylesheet per GML feature type.

2. The response content should be designed for on-screen rendering, not
machine consumption. Hence the focus on property titles instead of
database column names, and the inclusion of units of measure in the
property values.

3. No geometry. Like Tom said, there are a lot of organisations out
there who are happy to publish map images but will not expose the
underlying geometry, or even the bounding boxes of the features. There
are cases where it is not desirable for the user to know the coordinate
that they have queried. e.g. Threatened species locations.

4. The reason for the "link" element is to provide a path to geometry,
and other representations of the feature, if it is needed. I've assumed
HTTP GET here for the sake of simplicity, and because it is naturally 
a GET operation. A GetFeature query to a WFS, at any network location, 
could be URL encoded and provided via a link element.

The "link" element may be a bit contentious because it provides a
means for bypassing the need for registries (in this case). The 
WMS tells the client application where to find additional resources 
that are related to the feature. There is no need to store such 
information in a registry and have the client application construct 
a URI. It just finds the type of resource that it requires using 
the "rel" and "type" attributes and follows the "href" URI.

Re BXFS:
> This very simple format has been around for
> a couple of years now, and has proven itself (to CubeWerx, anyways)
> to be quite adequate for communicating layer and feature information.
> This is the primary format that our WMS client and server uses for
> GetFeatureInfo requests.

Good to know that it works in the real world. Has BXFS been offered to
OGC for discussion?

Richard Gould wrote:
> One of the problems that we have had with GetFeatureInfo is the lack of 
> a mechanism to perform a query using a bounding box, rather than a 
> single point.

>From my perspective the query request mechanism (point/"what's this" vs
box/"what are these") is a separate issue. However, I cannot see why the
response format that I have suggested, or BXFS, could not handle the 
response for a bounding box query.

Andrew