[wms-dev] GetFeatureInfo queries using bounding box

[GeoPraxis Inc]

>> Stephen Kilburn wrote:
>> 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.
>
> Jeroen Ticheler wrote:
>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).

I have to admit that a couple projects I have been involved in implemented
box queries, circle queries and ad hoc polygon queries, all using ArcIMS as
the underlying engine.  In fact the box query was dead simple to add because
we implemented the standard GetFeatureInfo point query using a box, sized to
one pixel by default, but with an internal server setting to allow the box
size to be expanded to n pixels per side.  (This dealt with the issue raised
in Lance Dyas's [apparently cut off] post mentioning ErrorRadius on 17
January.  He raised a good point.  In fact, we lobbied ESRI to add this
functionality to ArcIMS and the associated WMS products after having to
implement a workaround for selecting points in an ArcIMS 3 application.)

I submit that since we are in the business of promoting published
vendor-independent specifications, we:  (a) have to strive to make them as
consistent and flexible for meeting the broadest spectrum of user
requirements possible; (b) should make various specifications (e.g. WMS and
WFS) as compatible with each other as possible; and (c) have to take care
not to make the lives of those who are supporting existing versions of the
specifications difficult.

Unfortunately, the first and third goals stand somewhat in opposition to
each other.  I think most would agree that the existing versions of the WMS
spec have significant limitations and shortcomings.  (This current
discussion revolves around one particular issue.)  At the same time, there
is a lot of inertia built up among a lot of different parties supporting
these versions, warts and all, and the whole overhang of the current one
having been made an ISO standard.

I think, for better or worse, that we should accept that we should no longer
propose incremental spec changes that serve some needs, even if some fairly
widely used software can/does support additional functionality.  Instead,
let's talk about what the spec should look like, given the benefit of our
experience in using the current iterations, and put into place, after a
thoroughgoing discussion, a new version robust enough that it can serve as a
stable platform for applications and not frustrate those who use it or tempt
them to break compatibility by adding vendor-specified parameters.

<steps off soap box> :-)
_____________________________________________________________
Stephen Kilburn
GeoPraxis Inc.