[wms-dev] Suggestion for Common GetFeatureInfo Response Format

[Kralidis,Tom [Burlington]]

Hi,

I think this is much need in the WMS community.  There are a lot of
folks out there who don't want to serve their OGC:WMS as additionally
OGC:WFS, and are more comfortable with giving less with GetFeatureInfo
than GetFeature.  It's true that someone could (if they really wanted
to) fetch a dataset with some smart GetFeature scanning, but still.

At any rate, some normalized GetFeatureInfo output would be great.
Perhaps GML3L0?

..Tom


> -----Original Message-----
> From: wms-dev-bounces at lists.eogeo.org 
> [mailto:wms-dev-bounces at lists.eogeo.org] On Behalf Of Richard Gould
> Sent: Monday, January 16, 2006 1:55 PM
> To: wms-dev at lists.eogeo.org
> Cc: Andrew Hallam
> Subject: Re: [wms-dev] Suggestion for Common GetFeatureInfo 
> Response Format
> 
> 
> 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
> _______________________________________________
> wms-dev mailing list
> wms-dev at lists.eogeo.org 
> http://lists.eogeo.org/mailman/listinfo/wms-dev
>