[wms-dev] Suggestion for Common GetFeatureInfo Response Format

[Keith Pomakis]

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

Andrew Hallam replied:
> 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".
>
> [...]
> Stuff that's in my head:
>
> [...]
> 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.

I'd like to point out that most things in the BXFS schema are optional,
so if a server doesn't want to provide geometries in a GetFeatureInfo
response (and my guess is that most won't), then it simply doesn't
provide them.

> 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.

Every "thing" in a BXFS data stream can have a Description object attached
to it, which can contain a title, an abstract and a metadata URL.  Perhaps
this metadata URL can be used to communicate such a link.  Another option,
of course, is to define BXFS 0.0.2 which adds a Link element.

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

Actually, it has, a couple of years ago as a simpler alternative to GML.
However, at the time, the powers-that-be decided to focus on GML instead.
I don't think it's ever too late to re-consider BXFS as a standard for
situations in which GML is considered overkill.

One other comment I'd like to make is about MIME types.  The "Proposed
Response Format" in "Improving WMS GetFeatureInfo - Part 2" is
"text/xml", with perhaps a vendor-specific element to indicate the
schema of the response.  However, there is a much cleaner way of
handling this, without the need for vendor-specific elements.  The "OWS
Common Implementation Specification" (OGC document 03-088r6), section
12.7, states:

    The basic structure of a MIME type is a string of the form
    "type/subtype". MIME allows additional parameters in a string of
    the form "type/subtype; param1=value1; param2=value2". A server may
    include parameterized MIME types in its list of supported output
    formats. In addition to any parameterized variants, the server
    should offer the basic unparameterized version of the format.

The CubeWerx WMS uses such parameterized MIME types to communicate more
specific information as to the formats supported.  For example, the
GetMap operation is described in our capabilities document as follows:

  <Operation name="GetMap">
    <Format>image/png</Format>
    <Format>image/png; PhotometricInterpretation=PaletteColor</Format>
    <Format>image/png; PhotometricInterpretation=RGB</Format>
    <Format>image/tiff</Format>
    <Format>image/tiff; PhotometricInterpretation=RGB</Format>
    <Format>image/gif</Format>
    <Format>image/jpeg</Format>
    <Format>image/ppm</Format>
    [...]

So, for example, if a client cares about getting a PaletteColor versus
an RGB image back, it may request that specifically.  Otherwise, if it
doesn't care (or is oblivious to parameterized MIME types), it would
simply request the base type (e.g., "image/png").

An example that's more relevant to the current discussion is the
description of the GetFeatureInfo operation in our capabilities document:

  <Operation name="GetFeatureInfo">
    <Format>text/html</Format>
    <Format>text/xml; subtype="gml.1"</Format>
    <Format>application/x-bxml; version="0.0.8"; subtype="gml.1"</Format>
    <Format>text/xml; subtype="bxfs/0.0.1"</Format>
    <Format>application/x-bxml; version="0.0.8"; subtype="bxfs/0.0.1"</Format>
    <Format>application/x-cubestor-any</Format>
    [...]

As you can see here, we offer two different "text/xml" responses,
that being BXFS and GML.1 (an archaic response type that we continue
to support for backward-compatibility reasons).  In this particular
situation, and in my opinion with GetFeatureInfo in general, it's
meaningless to provide an unparameterized "text/xml" response type,
because that would leave the client guessing as to what it might
get back.

.-------------------------------------------+-------------------------------.
| Keith Pomakis                             | E-mail: pomakis at cubewerx.com  |
| Senior Software Developer, CubeWerx Inc.  | Phone:  (819) 771-8303 x204   |
| 15 rue Gamelin, Gatineau, Québec J8Y 3B5  | Fax:    (819) 771-8388        |
+-------------------------------------------+-------------------------------+
|              WWW home page: "http://www.pobox.com/~pomakis/"              |
`---------------------------------------------------------------------------'