[mapguide-internals] RFC39 - Ready For Review - "Add layer name toWMS GetFeatureInfo response"

[Thomas M. Tuerke]

The GFI request has historically been "weak" in terms of the information it provides... typically just human-readable content, with little machine-readable value.  My sense is that the drafters originally contemplated it for putting into a "popup" or status panel, but not for the client machine to do much with beyond that.

>From the WMS 1.1.1 spec: (-->>emphasis mine<<--)
The GetFeatureInfo operation is designed to provide clients of a WMS with more information about features in the pictures of maps that were returned by previous Map requests. -->>The canonical use case for GetFeatureInfo is that a user sees the response of a Map request and chooses a point on that map for which to obtain more information.<<-- The basic operation provides the ability for a client to specify which pixel is being asked about, which layer(s) should be investigated, and what format the information should be returned in. Because the WMS protocol is stateless, the GetFeatureInfo request indicates to the WMS what map the user is viewing by including most of the original GetMap request parameters (all but VERSION and REQUEST). From the spatial context information (BBOX, SRS, WIDTH, HEIGHT) in that GetMap request, along with the X,Y position the user chose, the WMS can (possibly) return additional information about that position. The behavior described above is geared toward the picture case. In the graphic element case, the semantics of GetFeatureInfo are less defined. -->>The intent is to gain experience with this version of the request and perhaps provide additional rigor in future versions of the specification.

The actual semantics of how a WMS decides what to return more information about, or what exactly to return is left up to the WMS provider.<<--

As such, we allowed the templates to define what GFI returns, based on the installation's knowledge of the information it can provide... (and with a wink and a nod that it's really just suitable for human eyes, unless somebody comes along with a more rigorous response type.)

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Tuesday, October 09, 2007 10:09 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC39 - Ready For Review - "Add layer name toWMS GetFeatureInfo response"


Wow, just re-read the spec for GetFeatureInfo (even at 1.3), and am once
again wondering why they even bothered to include it.  There is no way
of reliably using the information returned from any server, without
having a knowledge of that server's implementation.

Since there is no guidance at all on what should be included in the
response to this query, I'm OK with this workaround.  It doesn't seem
"right" to bake application-specific logic into WMS, but it seems to be
what the spec requires...

I'm thinking that for this kind of application WFS would be a better
approach anyway?  Not knowing anything about WFS, is there a way of
redirecting WMS GetFeatureInfo to WFS resources?  Or using a WFS
response to GetFeatureInfo (not sure if this problem exists in WFS as
well, or if it's specifically constrained to single-layer access)?

Jason

-----Original Message-----
From: Chris Claydon
Subject: [mapguide-internals] RFC39 - Ready For Review - "Add layer name
toWMS GetFeatureInfo response"

MapGuide Open Source RFC 39 is now ready for review. It can be found at
the following location:

http://trac.osgeo.org/mapguide/wiki/MapGuideRfc39

_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals