[wms-dev] Suggestion for Common GetFeatureInfo Response Format

[Keith Pomakis]

Andrew Hallam wrote:
> Back in October 2004 I sent a message to this list asking about
> "Mandatory GetFeatureInfo Response Format(s)". I was reminded of this
> issue recently while looking at a registry problem.
>
> In an attempt to rekindle the discussion I've put together a suggested
> GetFeatureInfo response format and posted it on my weblog. Your comments
> would be most welcome.

In short, I like it.  The GetFeatureInfo protocol has, in my opinion,
been way underutilized, and that's mostly because none of the clients and
servers (other than those created specifically to be used together) know
what to communicate.  This issue is especially important to CubeWerx,
because our WMS cascades information from other WMSs, and so having
one or more agreed-upon format would take the data long way, literally.

I'd like to point out one further reason for the "XML, not GML" argument.
The WMS specification does not limit what a layer name can look like
(i.e., its structure and alphabet, etc.).  I think this is a very good
thing, because the one of the great powers of the WMS specification is
that it does not make any assumptions as to what the underlying database
system is.  For example, a WMS server is free to name its layers "Rivers
In Ontario", or "Rivers:Ontario:Canada", or "Rivers&Lakes".  Again,
this is a good thing, and CubeWerx's WMS, for example, has been taking
advantage of this flexibility for quite some time.  GML, however, places
strong restrictions on the structure and alphabet of a layer (feature
type) name, since these names must be valid XML element names.  None of
the abovementioned layer names can be communicated via GML.  How this
horrible restriction is disregarded by GML advocates as irrelevant is
beyond me.  It makes the implicit assumption that all data is stored
and/or managed as XML.  This is a bold, and in my opinion unreasonable,
assumption to make.  So having a simple agreed-upon format which can
communicate things like layer names without making assumptions as to
the structure and alphabet of the names is something that I think we
desperately need.

At the risk of complicating things, though, may I suggest BXFS as
another alternative?  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.

Some of its powers (other than its simplicity) include:

   - It can communicate a herogeneous collection of more than one feature
     set at once.

   - It can communicate the full data-type schema (in the generic sense,
     not in the XML sense) of each feature type.

   - It can (optionally) communicate the bounding box(es) of each
     feature set.

   - It can (optionally) communicate the properties of each feature.

   - It can (optionally) communicate the full geometry of each feature.

   - It can provide a mapping from property names to human-readable
     titles (so, for example, the client can choose whether to show the
     name 'schema.water_bores.depth_in_metres' or the title "Depth").

   - It can provide a mapping from property values to human-readable
     titles.

The MIME type for BXFS is:

    text/xml; subtype="bxfs/0.0.1"

Its schema can be found here:

    http://schemas.cubewerx.com/schemas/bxfs/0.0.1/BXFS.xsd

Here is a sample GetFeatureInfo query that asks for BXFS:

    http://demo.cubewerx.com/demo/cubeserv/cubeserv.cgi?CONFIG=main&SERVICE=WMS&VERSION=1.3.1&REQUEST=GetFeatureInfo&CRS=EPSG%3A4326&BBOX=36.34867318093068,-86.73316550660398,46.40980436306932,-71.64146873339602&WIDTH=600&HEIGHT=400&LAYERS=POLBNDL_1M%3AFoundation,COASTL_1M%3AFoundation,BUILTUPA_1M%3AFoundation&STYLES=,,&FORMAT=image%2Fpng%3B+PhotometricInterpretation%3DPaletteColor&BGCOLOR=0xFFFFFF&TRANSPARENT=FALSE&EXCEPTIONS=HTML&QUALITY=MEDIUM&QUERY_LAYERS=BUILTUPA_1M%3AFoundation&INFO_FORMAT=text%2Fxml%3B+subtype%3D%22bxfs%2F0.0.1%22&I=435&J=39&RADIUS=5&FEATURE_COUNT=3

Here is the same request, but asking for the full geometries as well
(using a vendor-specific parameter):

    http://demo.cubewerx.com/demo/cubeserv/cubeserv.cgi?CONFIG=main&SERVICE=WMS&VERSION=1.3.1&REQUEST=GetFeatureInfo&CRS=EPSG%3A4326&BBOX=36.34867318093068,-86.73316550660398,46.40980436306932,-71.64146873339602&WIDTH=600&HEIGHT=400&LAYERS=POLBNDL_1M%3AFoundation,COASTL_1M%3AFoundation,BUILTUPA_1M%3AFoundation&STYLES=,,&FORMAT=image%2Fpng%3B+PhotometricInterpretation%3DPaletteColor&BGCOLOR=0xFFFFFF&TRANSPARENT=FALSE&EXCEPTIONS=HTML&QUALITY=MEDIUM&QUERY_LAYERS=BUILTUPA_1M%3AFoundation&INFO_FORMAT=text%2Fxml%3B+subtype%3D%22bxfs%2F0.0.1%22&I=435&J=39&RADIUS=5&FEATURE_COUNT=3&GET_GEOMETRIES=TRUE

(If those URLs don't work for you, try these URLs instead:
"http://tinyurl.com/a7xz8" and "http://tinyurl.com/dhebk".)

Providing support for the latter request (with GET_GEOMETRIES=TRUE)
allows the WMS to be used as a sort of a mini non-transactional WFS,
allowing WMS clients to fetch actual geometries to be plotted rather
than simply images.

But I digress.  My main point is to say that I agree with Andrew that
we need a simple agreed-upon format for communicating GetFeatureInfo
responses.  The specific schema he provided for a possible solution is
certainly one option.  Another option is BXFS, which, experience has
shown us, is flexible enough to be be used in a variety of other ways
as well while still being incredibly simple.

.-------------------------------------------+-------------------------------.
| 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/"              |
`---------------------------------------------------------------------------'