msQueryByRect does not use tolerance

[bartvde]

I just checked the msQueryByRect() code and it doesn't seem to use tolerance. I think it should so this is a bug. The fix should be relatively simple: expand the search rect by the layers tolerance value and then proceed as normal. If you'd create a ticket and perhaps a test case I'd be happy to fix this ASAP in 5.6 and trunk...

Steve

-----Original Message-----
From: mapserver-dev-bounces@lists.osgeo.org [mailto:mapserver-dev-bounces@lists.osgeo.org] On Behalf Of Bart van den Eijnden
Sent: Sunday, May 09, 2010 2:12 PM
To: MapServer Dev Mailing List
Subject: [mapserver-dev] WFS BBOX on point layers

Hi list,

when a very small BBOX filter is sent to Mapserver WFS, and the source layer is a point layer, it is very hard to actually select the point, normally no result is given.

Does Mapserver use TOLERANCE in this particular case? I can't seem to influence the situation by increasing TOLERANCE.

Using MS 5.4.

TIA.

Best regards,
Bart

[aboudreault]

I'm going to check this one Steve. I assume msQueryByRect only needs to adjust the search rect with the tolerance given.

[aboudreault]

Fixed and committed in r10211. Steve, could you take a quick look to see if the patch is ok? If so, you can close the ticket.

[sdlime]

I think that's fine, at first glance anyway. I was figuring on just expanding the search rect. Bart, have you tested on your end? I'm going to mark as closed.

Thanks for fixing Alan!

Steve

[bartvde]

I am testing this right now, and it works as expected.

However, if people have been using e.g. a TOLERANCE value on their POLYGON layers (like some of our MAP files have), then SLD's can come out differently, i.e. selecting more polygons than in previous versions of Mapserver. Maybe something should be added to the migration guide?

[bartvde]

This change seems to also create some impossible situations. Imagine the following:

1) a line layer for which WMS GetFeatureInfo and WFS GetFeatureInfo is used 2) for WMS GetFeatureInfo to work properly, TOLERANCEUNITS of PIXELS is needed, and e.g. at tolerance of 3, 4 or 5 pixels. 3) however, this messes up BBOX queries in WFS, since 5 pixels is very large depending on the MAP->EXTENT and MAP->SIZE.

Does anyone have a solution to this problem with the current state of affairs?

[bartvde]

I meant WFS GetFeature in the above sentence.

[sdlime]

I'm starting to think we should support tolerance for POINT queries only regardless of interface...

Why is "TOLERANCEUNITS PIXELS" needed. Granted that's the default units. Problem is more that there are default TOLERANCE values at all isn't it?

Steve

[bartvde]

Hey Steve, I am also starting to think this change was a bad idea, even though it fixed a problem for me back then.

[sdlime]

Actually I think the a tolerance here is ok, we do it for the point and shape queries. I think the problem is that default tolerance is in pixels. The tolerance concept was put in place when queries were done based on clicking in an another image and that's just not always the case. You see the problem when you don't explicitly set tolerance values for line and point layers, correct? Polygon layers have a tolerance of 0. Anyway, what I'd favor is setting the default tolerance for all feature types to 0. That would force users to configure things explicitly. I think the "no results" case is easier to debug as opposed "wrong results". Acually I think the default tolerance is 0, but it's changed in the various query functions.

My two cents...

Steve

[bartvde]

Hi Steve, no that's not the issue I am describing. We specifically specify the tolerance in the line layer ourselves, to get good results on WMS GetFeatureInfo clicks. However, the same tolerance setting is far from ideal for the WFS BBOX requests. We get back too much data then, some of which is not relevant at all for the query.

[sdlime]

Let's say they the issues are related. WMS clicks behave like old-fashioned apps where things work in pixels don't they? You pass a click xy, image extent and size. In that case pixel tolerances work fine, that's that they were designed for. Pixel tolerances don't work well when you pass pure map coordinates because they pick up the default extent and image size which can result in large values.

Pixel tolerances were added to provide a consistent buffer around features (in pixels) regardless of image resolution. You certainly can set non-pixel tolerances/units that will make WMS work AND WFS work. That's the fix on your side I guess, don't use pixel tolerances for WFS layers. You could configure 1 layer for WMS with pixel tolerances and another for WFS with unit-based tolerances I suppose.

Steve

[bartvde]

Hey Steve, we could not find a good tolerance in meters to fit both WMS and WFS. To get decent results at a scale of the country, we needed to do something like 5000 meters tolerance, which is way too much for large-scale WFS requests.

[sdlime]

That points to separate layers or mapfiles I think, at least as the code sits. Ideas moving forward might include:

• metadata-based configuration of certain params like this based on service (e.g. "wms_query_tolerance" "5,pixels")
• conditional mapfile blocks (if WMS use this, if WFS use this)

The first option would be much easier to implement.

Steve