[Geoserver-devel] Adding support for controlling GetFeatureInfo search radius

Andrea_Aime3 · March 25, 2009, 2:00pm

Hi all,
I've been contracted to add support for controlling
the GetFeatureInfo radius. The way I allow the control
has not been specified, but I need this to be part
of the 1.7.4 release, or else I'll be forced to make
custom builds for the contractor.

Given this is a feature that has been requested many
times I'd lend towards including it into the release,
but I'll respect whatever decision the GeoServer PSC
takes.

As for the how, well, I see two paths:
- adding the radius as a WMS service option, stored
   on disk, but not exposed in the 1.7.x UI (with
   the idea to expose it in the new UI for 2.0)
- adding is as a vendor parameter in the
   GetFeatureInfo request, e.g., &radius=20

The latter seems to be a more promising one.
I just have one reservation, which is, it
makes it possible to abuse GetFeatureInfo
to get an equivalent of a GetFeature, which
the admin might have disabled.
This falls in the topic of making WMS more
constrained, more controllable by the
administrator, and there are a number of
other ways WMS can be abused.
I'd say I should go for the vendor param,
and plan to add in the future some control
mechanism in the configuration setting a max
acceptable radius inside the wms config
(as well as other parameters, such as
max image size, max time alloted for the
request, and so on)

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Gabriel_Roldan2 · March 25, 2009, 2:38pm

Andrea Aime wrote:

Hi all,
I've been contracted to add support for controlling
the GetFeatureInfo radius. The way I allow the control
has not been specified, but I need this to be part
of the 1.7.4 release, or else I'll be forced to make
custom builds for the contractor.

Given this is a feature that has been requested many
times I'd lend towards including it into the release,
but I'll respect whatever decision the GeoServer PSC
takes.

As for the how, well, I see two paths:
- adding the radius as a WMS service option, stored
   on disk, but not exposed in the 1.7.x UI (with
   the idea to expose it in the new UI for 2.0)
- adding is as a vendor parameter in the
   GetFeatureInfo request, e.g., &radius=20

The latter seems to be a more promising one.
I just have one reservation, which is, it
makes it possible to abuse GetFeatureInfo
to get an equivalent of a GetFeature, which
the admin might have disabled.
This falls in the topic of making WMS more
constrained, more controllable by the
administrator, and there are a number of
other ways WMS can be abused.
I'd say I should go for the vendor param,
and plan to add in the future some control
mechanism in the configuration setting a max
acceptable radius inside the wms config
(as well as other parameters, such as
  max image size, max time alloted for the
  request, and so on)

I'd say that's the better option to me: admin configs the max allowable search ratio, vendor param constrained to that value but allows to specify a lower/equal one, just like in wfs maxFeatures?

Good stuff, and long awaited one.

Cheers,
Gabriel

Cheers
Andrea

Andrea_Aime3 · March 25, 2009, 2:52pm

Gabriel Roldan ha scritto:

Andrea Aime wrote:

Hi all,
I've been contracted to add support for controlling
the GetFeatureInfo radius. The way I allow the control
has not been specified, but I need this to be part
of the 1.7.4 release, or else I'll be forced to make
custom builds for the contractor.

Given this is a feature that has been requested many
times I'd lend towards including it into the release,
but I'll respect whatever decision the GeoServer PSC
takes.

As for the how, well, I see two paths:
- adding the radius as a WMS service option, stored
   on disk, but not exposed in the 1.7.x UI (with
   the idea to expose it in the new UI for 2.0)
- adding is as a vendor parameter in the
   GetFeatureInfo request, e.g., &radius=20

The latter seems to be a more promising one.
I just have one reservation, which is, it
makes it possible to abuse GetFeatureInfo
to get an equivalent of a GetFeature, which
the admin might have disabled.
This falls in the topic of making WMS more
constrained, more controllable by the
administrator, and there are a number of
other ways WMS can be abused.
I'd say I should go for the vendor param,
and plan to add in the future some control
mechanism in the configuration setting a max
acceptable radius inside the wms config
(as well as other parameters, such as
  max image size, max time alloted for the
  request, and so on)


I'd say that's the better option to me: admin configs the max allowable search ratio, vendor param constrained to that value but allows to specify a lower/equal one, just like in wfs maxFeatures?

That sounds like a good idea but above I said adding the vendor
parameter now and the max radius control later when the full
set of WMS control shortcomings is addressed.

Are you asking me to do both now in order to go on with the patch on 1.7.x? I can try in fact, it would have some backward compatility
issue... for example, what's the default max radius if none
is set (think upgrading a data dir)?

Atm we have 2 pixel radius, fixed. What would be the
default max radius? 10? 100?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Gabriel_Roldan2 · March 25, 2009, 3:13pm

Andrea Aime wrote:

Gabriel Roldan ha scritto:

Andrea Aime wrote:

Hi all,
I've been contracted to add support for controlling
the GetFeatureInfo radius. The way I allow the control
has not been specified, but I need this to be part
of the 1.7.4 release, or else I'll be forced to make
custom builds for the contractor.

Given this is a feature that has been requested many
times I'd lend towards including it into the release,
but I'll respect whatever decision the GeoServer PSC
takes.

As for the how, well, I see two paths:
- adding the radius as a WMS service option, stored
   on disk, but not exposed in the 1.7.x UI (with
   the idea to expose it in the new UI for 2.0)
- adding is as a vendor parameter in the
   GetFeatureInfo request, e.g., &radius=20

The latter seems to be a more promising one.
I just have one reservation, which is, it
makes it possible to abuse GetFeatureInfo
to get an equivalent of a GetFeature, which
the admin might have disabled.
This falls in the topic of making WMS more
constrained, more controllable by the
administrator, and there are a number of
other ways WMS can be abused.
I'd say I should go for the vendor param,
and plan to add in the future some control
mechanism in the configuration setting a max
acceptable radius inside the wms config
(as well as other parameters, such as
  max image size, max time alloted for the
  request, and so on)


I'd say that's the better option to me: admin configs the max allowable search ratio, vendor param constrained to that value but allows to specify a lower/equal one, just like in wfs maxFeatures?

That sounds like a good idea but above I said adding the vendor
parameter now and the max radius control later when the full
set of WMS control shortcomings is addressed.

Are you asking me to do both now in order to go on with the patch on 1.7.x? I can try in fact, it would have some backward compatility
issue... for example, what's the default max radius if none
is set (think upgrading a data dir)?

Atm we have 2 pixel radius, fixed. What would be the
default max radius? 10? 100?

ok, yeah, I'm saying you maybe could add the max option as a configuration setting right now but not adding the config option to the ui so you have less code to change afterwards. About the backwards compatibility concern, if in 1.7.3 you're having a fixed 2 pixel radius and you change that to another default value, whether it is 10 or 100, the result is gonna be you'll hopefully start getting results at locations were you weren't before, so that seems to me more as an improvement than going to break anything?

what a sensible default value might be I'm not that sure... may be 100 is too much and 10 too little? do you have a concrete use case (= marker symbols for your project) you need to make sure are hit?

Cheers,

Gabriel

Cheers
Andrea

Andrea_Aime3 · March 25, 2009, 3:41pm

Gabriel Roldan ha scritto:

Atm we have 2 pixel radius, fixed. What would be the
default max radius? 10? 100?

ok, yeah, I'm saying you maybe could add the max option as a configuration setting right now but not adding the config option to the ui so you have less code to change afterwards.

Ok, I will try... as usual I'm bound to a short time to develop
the thing, but I will try, and if PSC demands for this, well,
I'll resort to using my spare time...
(this is not OpenGeo sponsored, it's something that my old company
is requesting for and they still own a few days of my consultancy)

> About the backwards

compatibility concern, if in 1.7.3 you're having a fixed 2 pixel radius and you change that to another default value, whether it is 10 or 100, the result is gonna be you'll hopefully start getting results at locations were you weren't before, so that seems to me more as an improvement than going to break anything?

I don't mean to change the default radius, on the contrary, I'll
keep it 2 pixels for backwards compatibility.
My question is another.
If we are adding a maxRadius setting in services.xml, what is
going to be its default value when it's not specified? Because
lots of people will upgrade with data directories that do not
contain any maxRadius, thus we need a default for it.

what a sensible default value might be I'm not that sure... may be 100 is too much and 10 too little? do you have a concrete use case (= marker symbols for your project) you need to make sure are hit?

Nope, I don't. In fact they will need different search radiuses for
different layers (they build the GetFeatureInfo so that only
one layer at a time is queried).
As for the maxRadius default value, dunno... 50? This will mean
that by default &radius=xx won't be able to go over 50, no
matter what the user actually typed in the request.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Gabriel_Roldan2 · March 25, 2009, 5:01pm

Andrea Aime wrote:

Gabriel Roldan ha scritto:

Atm we have 2 pixel radius, fixed. What would be the
default max radius? 10? 100?

ok, yeah, I'm saying you maybe could add the max option as a configuration setting right now but not adding the config option to the ui so you have less code to change afterwards.

Ok, I will try... as usual I'm bound to a short time to develop
the thing, but I will try, and if PSC demands for this, well,
I'll resort to using my spare time...

well I'm not PSC nor in a position nor mood to require you anything was just trying to provide some feedback.

(this is not OpenGeo sponsored, it's something that my old company
is requesting for and they still own a few days of my consultancy)

understood.

> About the backwards

compatibility concern, if in 1.7.3 you're having a fixed 2 pixel radius and you change that to another default value, whether it is 10 or 100, the result is gonna be you'll hopefully start getting results at locations were you weren't before, so that seems to me more as an improvement than going to break anything?

I don't mean to change the default radius, on the contrary, I'll
keep it 2 pixels for backwards compatibility.
My question is another.
If we are adding a maxRadius setting in services.xml, what is
going to be its default value when it's not specified? Because
lots of people will upgrade with data directories that do not
contain any maxRadius, thus we need a default for it.

what a sensible default value might be I'm not that sure... may be 100 is too much and 10 too little? do you have a concrete use case (= marker symbols for your project) you need to make sure are hit?

Nope, I don't. In fact they will need different search radiuses for
different layers (they build the GetFeatureInfo so that only
one layer at a time is queried).
As for the maxRadius default value, dunno... 50? This will mean
that by default &radius=xx won't be able to go over 50, no
matter what the user actually typed in the request.

I would rather say 25, which makes a 50 pixel diameter circle around the clicked point... a circle of 100 pixel diameter sort of seems excessive to me...

Cheers,

Gabriel

Cheers
Andrea

Justin_Deoliveira · March 26, 2009, 3:57am

Andrea Aime wrote:

Hi all,
I've been contracted to add support for controlling
the GetFeatureInfo radius. The way I allow the control
has not been specified, but I need this to be part
of the 1.7.4 release, or else I'll be forced to make
custom builds for the contractor.

Given this is a feature that has been requested many
times I'd lend towards including it into the release,
but I'll respect whatever decision the GeoServer PSC
takes.

Hmmm... well we agreed during the last few road map updates that 1.7.x was bug fix only. While I personally don't mind to bend the rules in this case I think its appropriate to propose a formal amendment in the next road map update, and give people a chance to voice their opinion like we do with any other update.

I know this seems maybe a bit anal... but the process was put in place to ensure fairness. So let's stick to it. That said the nature of this feature is pretty minor so I can't really see any objections to this change.

As for the how, well, I see two paths:
- adding the radius as a WMS service option, stored
   on disk, but not exposed in the 1.7.x UI (with
   the idea to expose it in the new UI for 2.0)
- adding is as a vendor parameter in the
   GetFeatureInfo request, e.g., &radius=20

I like the vendor parmeter method as well.

The latter seems to be a more promising one.
I just have one reservation, which is, it
makes it possible to abuse GetFeatureInfo
to get an equivalent of a GetFeature, which
the admin might have disabled.
This falls in the topic of making WMS more
constrained, more controllable by the
administrator, and there are a number of
other ways WMS can be abused.
I'd say I should go for the vendor param,
and plan to add in the future some control
mechanism in the configuration setting a max
acceptable radius inside the wms config
(as well as other parameters, such as
max image size, max time alloted for the
request, and so on)

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

jive · March 26, 2009, 7:01am

Hi Andrea;

I have experimented in the past (from udig) with a "larger" get
feature info area; I performed this by changing the screen resolution
of the image I requested the info against. This was a change I could
make completely client side. We also experimented with making a the
get feature info request against a reference image that was a single
pixel (w=1, h=1) but some of the WMS implementations were unhappy with
this idea.

Given this is a feature that has been requested many
times I'd lend towards including it into the release,
but I'll respect whatever decision the GeoServer PSC
takes.

I am okay either way; but I am not sure I understand exactly what is
being requested. Are you changing the size based on pixels or world
units for example?

As for the how, well, I see two paths:
- adding the radius as a WMS service option, stored
on disk, but not exposed in the 1.7.x UI (with
the idea to expose it in the new UI for 2.0)
- adding is as a vendor parameter in the
GetFeatureInfo request, e.g., &radius=20

The latter seems to be a more promising one.
I just have one reservation, which is, it
makes it possible to abuse GetFeatureInfo
to get an equivalent of a GetFeature, which
the admin might have disabled.
This falls in the topic of making WMS more
constrained, more controllable by the
administrator, and there are a number of
other ways WMS can be abused.
I'd say I should go for the vendor param,
and plan to add in the future some control
mechanism in the configuration setting a max
acceptable radius inside the wms config
(as well as other parameters, such as
max image size, max time alloted for the
request, and so on)

What is the expected result of getFeatureInfo in this case (a web page or GML?)

I found that I was asked to make getFeatureInfo bigger to help people
click on points. As such you may wish to try a single pixel request;
and if it misses try a larger area.

Jody

Andrea_Aime3 · March 26, 2009, 7:37am

Jody Garnett ha scritto:

Hi Andrea;

I have experimented in the past (from udig) with a "larger" get
feature info area; I performed this by changing the screen resolution
of the image I requested the info against. This was a change I could
make completely client side. We also experimented with making a the
get feature info request against a reference image that was a single
pixel (w=1, h=1) but some of the WMS implementations were unhappy with
this idea.

Ugh... no wonder, that's not playing by the WMS rules, and
besides, it won't work. You change the map size, the
scale changes, what features are drawn might change due
to scale dependent SLD Rules. Not to mention that symbols
sized in pixels will occupy a much larger area when you
"zoom out" that way, the user clicks maybe 20 pixels away
from a red circle, and you zoom out, the red circles
suddenly covers the geographic area where the user clicked.

Given this is a feature that has been requested many
times I'd lend towards including it into the release,
but I'll respect whatever decision the GeoServer PSC
takes.

I am okay either way; but I am not sure I understand exactly what is
being requested. Are you changing the size based on pixels or world
units for example?

The search radius has always been 2 pixels, what I'm proposing
is to allow for n pixels, where n can be chosen by the user
in the request.
There is no world unit support, nor there will be with this
change, nor is implied by the WMS spec.

What is the expected result of getFeatureInfo in this case (a web page or GML?)

How is this any relevant? The GFI output is completely orthogonal
to the way we query the data source.

I found that I was asked to make getFeatureInfo bigger to help people
click on points. As such you may wish to try a single pixel request;
and if it misses try a larger area.

Progressive enlargement? And when do you stop growing... I guess
when the requested search radius is reached?
This is way more expensive (n queries instead of 1) and has its
own side effects, if you're querying against multiple layers
the first hit will stop this algorithm.
So if the user clicked on a layer group that contains a polygon
and a point layer, and he clicked on the point layer that happens
to use a big red circle, it may get back only the information
about the underlying polygon (because at 1 pixel you don't
get the point geometry in your search area).

It seems like a nice functionality, but given it's slower
and has side effects, it should be exposed as its own extra
vendor parameter. e.g., &progressive=true.
I don't have time for this, but I'll be happy to assist if
someone else wants to do it. Maybe create a improvement
request on jira so that we won't forget, and we can see
how many people express an interest in it?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.