Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

QueryByPoint Issues on 6.4.2 #5120

Closed
woodbri opened this issue Jul 13, 2015 · 5 comments
Closed

QueryByPoint Issues on 6.4.2 #5120

woodbri opened this issue Jul 13, 2015 · 5 comments

Comments

@woodbri
Copy link

woodbri commented Jul 13, 2015

Extracted from thread on mapserver-users:

According to the docs, the defaults are:

TOLERANCE 3
TOLERANCEUNITS pixels

and with:

QUERY_STRING='map=/maps/wms/bathymetry.map&mode=query&layers=model_query&mapxy=-100.98125+41.58125'

How is zoom calculated?

LAYER
NAME "model_query"
STATUS on
TYPE raster

TILEINDEX "NOAA_Coastal_Relief_Model/index.shp"
TILEITEM "LOCATION"
CLASS
TEMPLATE "/maps/wms/pixel.value.html"
END
END

Did this behavior change from 6.2.1 to 6.4.1? because it is not noted in the MIGRATION-GUIDE if it did. On 6.2.1 I get the following result:

Content-Type: text/html
<HTML
<HEAD><TITLE>MapServer Message</TITLE></HEAD
<!-- MapServer version 6.2.1 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG
SUPPORTS=PROJ SUPPORTS=GD SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO
SUPPORTS=SVG_SYMBOLS SUPPORTS=ICONV SUPPORTS=FRIBIDI
SUPPORTS=WMS_SERVER
SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT
SUPPORTS=WCS_SERVER SUPPORTS=SOS_SERVER SUPPORTS=FASTCGI
SUPPORTS=THREADS SUPPORTS=GEOS INPUT=JPEG INPUT=POSTGIS INPUT=OGR
INPUT=GDAL INPUT=SHAPEFILE -->
<BODY BGCOLOR="#FFFFFF"
msQueryByPoint(): Search returned no results. No matching record(s)
found.
</BODY></HTML>

which returns very quickly.

I rsynced the data and the mapfile for Ubuntu 12.04 to 14.04 and installed the mapserver package. Everything else appears to be working without a problem except this issue.

SOLVED:

I explicitly added:

TOLERANCE 1
TOLERANCEUNITS pixels

to my LAYER definition and now it works.

# /usr/lib/cgi-bin/mapserv QUERY_STRING='map=/maps/wms/bathymetry.map&mode=query&layers=model_query&mapxy=-100.98125+41.58125'
Content-Type: text/html

<HTML>
<HEAD><TITLE>MapServer Message</TITLE></HEAD>
<!-- MapServer version 6.4.1 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG OUTPUT=KML SUPPORTS=PROJ SUPPORTS=GD SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=SVG_SYMBOLS SUPPORTS=RSVG SUPPORTS=ICONV SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT SUPPORTS=WCS_SERVER SUPPORTS=SOS_SERVER SUPPORTS=FASTCGI SUPPORTS=THREADS SUPPORTS=GEOS INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE -->
<BODY BGCOLOR="#FFFFFF">
msQueryByPoint(): Search returned no results. No matching record(s) found.
</BODY></HTML>

So it looks like maybe the defaults are not getting initialized.
@woodbri
Copy link
Author

woodbri commented Jul 15, 2015

So an update after some more testing. While adding the explicit:

TOLERANCE 1
TOLERANCEUNITS pixels

seems to improve things, I am still getting getting occasional hanging (it is not actually hanging but returning millions of lines of NoData value. If I increase MAP SIZE from 700 700 to 4096 4096 it greatly reduces output to like about 30 lines of NoData value.

So as Thomas mention it is likely a result of the number of raster pixels under the screen pixel. Since I am doing a query to a GTiff, it seems that their should be no zoom scale applied, the resolution should be that of the georeferenced raster, the x-y of the query should find the neared pixel if it is over the raster and return no result if it is not over the raster in question.

The problem with this is the fact that this is a big change in behavior from 6.2 to 6.4 where 6.2 would return:

Content-Type: text/html

<HTML>
<HEAD><TITLE>MapServer Message</TITLE></HEAD>
<!-- MapServer version 6.2.1 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG OUTPUT=KML SUPPORTS=PROJ SUPPORTS=GD SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=SVG_SYMBOLS SUPPORTS=RSVG SUPPORTS=ICONV SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT SUPPORTS=WCS_SERVER SUPPORTS=SOS_SERVER SUPPORTS=FASTCGI SUPPORTS=THREADS SUPPORTS=GEOS INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE -->
<BODY BGCOLOR="#FFFFFF">
msQueryByPoint(): Search returned no results. No matching record(s) found.
</BODY></HTML>

and now 6.4 returns about 1 million by default according to:
http://mapserver.org/input/raster.html#raster-query

I have found that adding the following PROCESSING directive at least provides a way to limit the number of results, but at the default scale if there are millions of pixels at a coordinate which is returned. How are NoData values treated? are they ignored? If the x-y of the query resolves to NoData then it should respond the same way as if the x-y was not over the raster.

PROCESSING "RASTER_QUERY_MAX_RESULT=1"

The actual underlying raster is defined in my case like:

# gdalinfo /maps/wms/data/Bathy/NOAA_Coastal_Relief_Model/BSM-6252.tif
Driver: GTiff/GeoTIFF
Files: /maps/wms/data/Bathy/NOAA_Coastal_Relief_Model/BSM-6252.tif
Size is 4801, 4801
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (-126.000833330000006,41.000817329999997)
Pixel Size = (0.000833330000000,-0.000833330000000)
Metadata:
  AREA_OR_POINT=Point
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (-126.0008333,  41.0008173) (126d 0' 3.00"W, 41d 0' 2.94"N)
Lower Left  (-126.0008333,  37.0000000) (126d 0' 3.00"W, 37d 0' 0.00"N)
Upper Right (-122.0000160,  41.0008173) (122d 0' 0.06"W, 41d 0' 2.94"N)
Lower Right (-122.0000160,  37.0000000) (122d 0' 0.06"W, 37d 0' 0.00"N)
Center      (-124.0004247,  39.0004087) (124d 0' 1.53"W, 39d 0' 1.47"N)
Band 1 Block=256x256 Type=Float32, ColorInterp=Gray
  NoData Value=-99999
  Overviews: 2401x2401, 1201x1201, 601x601, 301x301, 151x151, 76x76, 38x38

@woodbri
Copy link
Author

woodbri commented Jul 15, 2015

Steve L noted that setting TOLERANCE 0 will return only the pixel at the coordinate and this does indeed trigger the old behavior for my limited test case. So maybe the only change that is needed it to default TOLERANCE 0 to get the old behavior or if there is some reason that it needs to be set the way it is now, then to update the MIGRATION-GUIDE to not that this needs to change in existing mapfiles that do queries.

@murdav murdav mentioned this issue Oct 1, 2015
Closed
@murdav
Copy link

murdav commented Oct 1, 2015

I just submitted a similar issue (#5173)

@jratike80
Copy link

Closing without trying to re-produce. I am sure that tolerance works as expected for some users with maxscaledenom. Refresh the ticket with a re-producible test case for MS 7.x or 8.x if needed.

@jratike80
Copy link

jratike80 commented Oct 25, 2023 •
edited
Loading

Closing without trying to re-produce. Refresh the ticket with a re-producible test case for MS 7.x or 8.x if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@woodbri @murdav @jratike80