[wms-dev] Suggestion for Common GetFeatureInfo Response Format

[Chuck Morris]

Andrew Hallam wrote:
>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.

This has sparked a good discussion, and I'd like to add my $.02 worth.

I also like the idea of a standard GetFeatureInfo response format and feel
that GML does not fit the bill.

I generally like the format Andrew Hallam suggested on his blog
(http://www.digitalearth.com.au/2006/01/05/improving-wms-getfeatureinfo-part-2/),
but I have reservations about the "links" in the format.  Andrew
suggested adding two types of hyperlinks to features, for alternate
representations of the feature and for related resources.

The "alternate representation" links don't seem useful to me since info
formats supported are already advertised in the capabilities document.  For
the rare cases where useful alternate representations exist on a remote
server, the server could just retrieve the remote representation and pass it
on to the client in a transparent manner.  Keeping the interface simple is
more important than keeping the server implementation simple, IMHO.

The "related resource" links may be useful in some contexts, but once you
start adding special-purpose fields like this, I think you start sliding
down a slippery slope toward unmanageable complexity.  Title, type, and href
may be all the attributes you want to define the link, but others are sure
to think of more attributes that they have to have (author, date, abstract,
etc.).  And of course, others will want additional types of special-purpose
fields relating to the feature (stylesheets, comments, effectivity dates,
symbology, etc., etc.).

So to avoid quagmire, my recommendation would be to leave all
special-purpose fields (including the links) out altogether.

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

The BXFS format does look interesting, but better suited for creating tables
for displaying multiple features (a header row plus 1 row per feature)
rather than single features (a 2-column table with name/value pairs).  Since
GetFeatureInfo requests generally only return one feature per layer, I think
most clients would choose to create 2-column tables.  Also I think the
server should be responsible for translating coded property values into
human readable values rather than just providing a mapping in BXFS which
clients would have to be prepared to handle.  So my vote would be for
something closer to Andrew's format than BXFS.

---

A related issue worth considering is whether we want to support multiple
FeatureInfo "styles".  For instance, it might be nice to display values in
either English or French, or using English or Metric units.  One way to
support this would be to use a "style" parameter in the MIME type.  Another
way would be to add <InfoStyle> elements in the <Layer> elements in the
capabilities document, and add an INFOSTLYES parameter to the GetFeatureInfo
request.  I think the latter approach would be better in the long run since
it would let you give human-friendly titles to your InfoStyles, but it does
have the disadvantage of being something that can't be implemented without a
change to the spec since it invloves changing the capabilities document in
one of the areas where there are no placeholders for vendor-specific
additions.  Anybody else have any thoughts on this?

- Chuck Morris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.eogeo.org/pipermail/wms-dev/attachments/20060120/cf6a77a7/attachment.htm