Hi all,
talking with Andreas Hocevar about the GetFeatureInfo radius issue
we realized we don't really need a new parameter, and we don't even
need the user to tell us what the radius is going to be (wow!).
See, in WMS we already have the "buffer" vendor parameter, which is
used to expand the area of the queried data to include the geometries
that lie outside of the painted area, but that do contribute to it
because of the size of their simbolizer.
Think for example about a point depicted as a 20pixel wide circle,
in order to include all the points contributing to the rendered
area we need to expand it by "10 pixels" (and turning those pixels
into a wider Envelope for the datastore query).
Well, see, the same param is really the search radius we want for
GetFeatureInfo! And there's more, we already have code that computes
the buffer automatically by SLD inspection: it scans the SLD
looking for sizes of the symbolizers and returns the largest,
or 0 in the case one of the sizes is an expression that depends
on an attribute (in that case we cannot tell what the right buffer
is going to be by just inspecting the SLD, we'd have to inspect
the feature data too). We take that value, divide it by two, done.
So, what I'm proposing is to:
- hook automatic radius evaluation into GetFeatureInfo
- use the same "buffer" parameter we already have, in the
case of GetFeatureInfo it will be the user specified search
radius (or search buffer, if you want)
Opinions?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
That is…
awesome!
well done guys.
Gabriel
On Wednesday 01 April 2009 07:46:35 Andrea Aime wrote:
Hi all,
talking with Andreas Hocevar about the GetFeatureInfo radius issue
we realized we don’t really need a new parameter, and we don’t even
need the user to tell us what the radius is going to be (wow!).
See, in WMS we already have the “buffer” vendor parameter, which is
used to expand the area of the queried data to include the geometries
that lie outside of the painted area, but that do contribute to it
because of the size of their simbolizer.
Think for example about a point depicted as a 20pixel wide circle,
in order to include all the points contributing to the rendered
area we need to expand it by “10 pixels” (and turning those pixels
into a wider Envelope for the datastore query).
Well, see, the same param is really the search radius we want for
GetFeatureInfo! And there’s more, we already have code that computes
the buffer automatically by SLD inspection: it scans the SLD
looking for sizes of the symbolizers and returns the largest,
or 0 in the case one of the sizes is an expression that depends
on an attribute (in that case we cannot tell what the right buffer
is going to be by just inspecting the SLD, we’d have to inspect
the feature data too). We take that value, divide it by two, done.
So, what I’m proposing is to:
- hook automatic radius evaluation into GetFeatureInfo
- use the same “buffer” parameter we already have, in the
case of GetFeatureInfo it will be the user specified search
radius (or search buffer, if you want)
Opinions?
Cheers
Andrea
–
Gabriel Roldan
http://www.opengeo.org
So, what I'm proposing is to:
- hook automatic radius evaluation into GetFeatureInfo
- use the same "buffer" parameter we already have, in the
case of GetFeatureInfo it will be the user specified search
radius (or search buffer, if you want)
+1. Sounds like the simplest to implement and at the same time the least intrusive.
Opinions?
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.