[wms-dev] GetFeatureInfo queries using bounding box

[Jeroen Ticheler]

>>> We have had a similar frustration in some projects.  However, if we
>>> want to crack open that "box" (as it were :-) ), IMO it would be
>>> better to go all the way and support queries based on the whole
>>> list of GML geometry classes.
>>
>> Isn't there a threshold of complexity here that, once crossed, would
>> suggest the use of a WFS? For instance, Points and BoundingBoxes are
>> easy to encode in HTTP GET URI. A box maps well to the relatively  
>> simple
>> action of dragging a rectangle on the user interface.
>
> True, but then so does a circle (click on centre and drag to the  
> radius),
> and so does a single line segment, both of which also could be  
> encoded in a
> request as a pair of points.  A point I was trying to make is that  
> if we
> start to talk about adding functionality to GetFeatureInfo in an ad  
> hoc
> manner, some favoured users will get their desired functionality  
> supported
> and some will be left having to use a WFS.  If we are proposing a  
> partway
> modification of the WMS spec, let's just leave it alone and say  
> that anybody
> who wants more than it can offer should use WFS.  That way, we  
> don't end up
> having servers supporting old versions of the spec not being forward
> compatible with servers supporting new versions, which introduces  
> the same
> kind of complications when a cascading server is involved.

Don't agree. Both MapServer and ArcIMS (the ones I know best) allow  
to query on a box. This is a very reasonable request and one that is  
implemented by many clients that use these servers directly (without  
OGC-WMS protocol).

Promoting WMS is a bit though from my experience because such a  
simple query can not be performed using the WMS protocol (although I  
manage to hide this lack in most cases :-( ).

It would be nice to see querying on all kind of geometries, but I  
don't think its something that could quickly be supported by most  
existing map servers and as such only delay implementation. They may  
come in next iterations of the protocol if need be, as I assume we  
don't want to stop development of the protocol for the future!?

Jeroen