[Geoserver-users] GetFeatureInfo Buffer/tolerance default

GeoServer GeoServer User
1

Hi List,
I’ve got a number of users who are experiencing issues with GetFeatureInfo not returning anything when they click a line feature. This is different from my previous email as those were polygons and there was no chance of missing.

In this case after careful study, it seems that users are commonly clicking what they think is on/near a feature, but GeoServer thinks it is a miss.
After quite a bit of searching I found out that GeoServer has a 2 pixel tolerance - http://docs.geoserver.org/stable/en/user/services/wms/vendor.html?highlight=getfeatureinfo#buffer

The below are two indications of what GeoServer considers a “miss” - the first one is within 2 pixels of the line border.

Inline images 1

Inline images 2

Two pixels seems extremely low. For comparison:

Any thoughts? Has anyone else had problems with this, or have their users have problems with it?

Cheers,
Jonathan

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

2

On Wed, Aug 7, 2013 at 5:01 PM, Jonathan Moules <
jonathanmoules@anonymised.com> wrote:

Hi List,
  I've got a number of users who are experiencing issues with
GetFeatureInfo not returning anything when they click a line feature. This
is different from my previous email as those were polygons and there was no
chance of missing.

In this case after careful study, it seems that users are commonly
clicking what they think is on/near a feature, but GeoServer thinks it is a
miss.
After quite a bit of searching I found out that GeoServer has a 2 pixel
tolerance -
http://docs.geoserver.org/stable/en/user/services/wms/vendor.html?highlight=getfeatureinfo#buffer

The documentation is outdated, and things are a bit more complicated.
First, the minimum is always 3 (not two).
Then, we always compute an optimal buffer based on the SLD if possible,
taking into account stroke
sizes and symbol sizes, and halving the largest of them to become the
search buffer (but if it gets
less than 3, then 3 is chosen). This does not always work, for example, if
the size of something is dependent
on an attribute, we cannot make a guess (we won't load all the dataset to
figure out what's the max value).

As an improvement, we could have the default buffer size be configurable
instead. We already have a max buffer
setting (since clients can add the &buffer=... parameter to modify the
geoserver behavior), we could have a min one as well.

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

3

Hi Andrea,
I did catch the section of the documentation about the SLD’s and the feature width being taken into account.
In this instance the feature width is explicitly defined as 1:

<se:SvgParameter name=“stroke-width”>1</se:SvgParameter>

However, if it is three, then I’m surprised that this click missed:

Inline images 1

The green dot is the click itself. It looks to be within 3 pixels of the blue line to me. I’m guessing “floor” or “round” is used for the rounding rather than “ceil”?

···

Hi List,
I’ve got a number of users who are experiencing issues with GetFeatureInfo not returning anything when they click a line feature. This is different from my previous email as those were polygons and there was no chance of missing.

In this case after careful study, it seems that users are commonly clicking what they think is on/near a feature, but GeoServer thinks it is a miss.
After quite a bit of searching I found out that GeoServer has a 2 pixel tolerance - http://docs.geoserver.org/stable/en/user/services/wms/vendor.html?highlight=getfeatureinfo#buffer

The documentation is outdated, and things are a bit more complicated.
First, the minimum is always 3 (not two).
Then, we always compute an optimal buffer based on the SLD if possible, taking into account stroke
sizes and symbol sizes, and halving the largest of them to become the search buffer (but if it gets
less than 3, then 3 is chosen). This does not always work, for example, if the size of something is dependent
on an attribute, we cannot make a guess (we won’t load all the dataset to figure out what’s the max value).

As an improvement, we could have the default buffer size be configurable instead. We already have a max buffer
setting (since clients can add the &buffer=… parameter to modify the geoserver behavior), we could have a min one as well.

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

4

On Wed, Aug 7, 2013 at 5:42 PM, Jonathan Moules <
jonathanmoules@anonymised.com> wrote:

Hi Andrea,
  I did catch the section of the documentation about the SLD's and the
feature width being taken into account.
In this instance the feature width is explicitly defined as 1:

<se:SvgParameter name="stroke-width">1</se:SvgParameter>

However, if it is three, then I'm surprised that this click missed:

!image.png|542x493

The green dot is the click itself. It looks to be within 3 pixels of the
blue line to me. I'm guessing "floor" or "round" is used for the rounding
rather than "ceil"?

No, you're hitting the line on an antialised pixel that the renderer added
to smooth the line itself, however
the tests are done in vector land, not raster one, so while visually you
might see a hits, the vector equivalent
might not have it. It's 3 pixels from the centerline.

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

5

Good point. I figured it was 3 pixels for the search, plus 0.5 for half the line width. In that case, at least visually in rasterland the pixel is within 3.5 pixels of the centreline, hence my comment about rounding.

image.png

···

Hi Andrea,
I did catch the section of the documentation about the SLD’s and the feature width being taken into account.
In this instance the feature width is explicitly defined as 1:

<se:SvgParameter name=“stroke-width”>1</se:SvgParameter>

However, if it is three, then I’m surprised that this click missed:

Inline images 1

The green dot is the click itself. It looks to be within 3 pixels of the blue line to me. I’m guessing “floor” or “round” is used for the rounding rather than “ceil”?

No, you’re hitting the line on an antialised pixel that the renderer added to smooth the line itself, however
the tests are done in vector land, not raster one, so while visually you might see a hits, the vector equivalent
might not have it. It’s 3 pixels from the centerline.

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

6

On Wed, Aug 7, 2013 at 5:59 PM, Jonathan Moules <
jonathanmoules@anonymised.com> wrote:

Good point. I figured it was 3 pixels for the search, plus 0.5 for half
the line width. In that case, at least visually in rasterland the pixel is
within 3.5 pixels of the centreline, hence my comment about rounding.

---
Back to the original thought, is it possible to increase the default? I
know quite a few of our users are missing the features, I wonder if that is
happening to other GeoServer users as well?
I think there's going to be a bias that 3 pixels is fine because,
technical types (the folks who implement GeoServer) usually have much
better mousing skills than general users. But that's just my theory; maybe
it's just a problem local to us.

As said, no problem implementing a default for the min value, provided that:
* there is resources to do so
* there is an understanding this is a new feature, and now we are in
feature freeze

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

7

My suggestion was more to change the actual default (3) itself for GeoServer to … 5? rather than add a new feature. I like the feature idea, but I think it only sidesteps the issue of the default being too low. Hence asking if other people/users are encountering problems with the current default of 3.
Regards,
Jonathan

···

Good point. I figured it was 3 pixels for the search, plus 0.5 for half the line width. In that case, at least visually in rasterland the pixel is within 3.5 pixels of the centreline, hence my comment about rounding.

Back to the original thought, is it possible to increase the default? I know quite a few of our users are missing the features, I wonder if that is happening to other GeoServer users as well?
I think there’s going to be a bias that 3 pixels is fine because, technical types (the folks who implement GeoServer) usually have much better mousing skills than general users. But that’s just my theory; maybe it’s just a problem local to us.

As said, no problem implementing a default for the min value, provided that:

  • there is resources to do so
  • there is an understanding this is a new feature, and now we are in feature freeze

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it