[wms-dev] Suggestion for Common GetFeatureInfo Response Format

[Richard Gould]

Keith Pomakis wrote:
> 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.

Andrew, this is excellent. We have been hoping for some sort of 
standardized response for GetFeatureInfo for a while. For uDig, we 
simply display the returned HTML in an embedded web browser. This makes 
for a very inconsistent user-experience when querying features from WMSs 
that return different HTML styles.

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

An excellent point. By default, each layer that a GeoServer serves up 
contains a ":", so yours would not be the only code affected.

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

BXFS sounds quite interesting, actually. I think it might definitely be 
worth looking into at least.

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.

I would love to see this become a standard.

Cheers,

Richard