mapscript raster query tests failing

[warmerdam]

In msautotest/mspython:

warmerda@gdal64[111]% ./run_all_tests.py
Running tests from ./rqtest.py
  TEST: rqtest_1 ... success
  TEST: rqtest_2 ... success
  TEST: rqtest_3 ... fail
    got 0 results instead of expected 55.
  TEST: rqtest_4 ... success
  TEST: rqtest_5 ... fail
    got 0 results instead of expected 9.
  TEST: rqtest_6 ... success
  TEST: rqtest_7 ... fail
    got 0 results instead of expected 1.
  TEST: rqtest_8 ... success
  TEST: rqtest_9 ... fail
    got 0 results instead of expected 100.
  TEST: rqtest_10 ... success
  TEST: rqtest_11 ... success
  TEST: rqtest_12 ... success
  TEST: rqtest_13 ... success
  TEST: rqtest_14 ... success
  TEST: rqtest_15 ... fail
    got 0 results instead of expected 10.
  TEST: rqtest_cleanup ... success

[warmerdam]

Steve,

the raster query test scripts look like this:

    pmstestlib.layer.queryByShape( pmstestlib.map, poly )
...
    #########################################################################
    # Check result count.
    layer.open()
    count = 0
    for i in range(1000):
        result = layer.getResult( i )
        if result is None:
            break
    
        count = count + 1

    if count != 55:
        pmstestlib.post_reason( 'got %d results instead of expected %d.' \
                             % (count, 55) )
        return 'fail'

Is this approach to using getResult() on a layer still supposed to work?

[warmerdam]

I think we should at least look into this issue before 5.6 is finalized, setting the milestone for now.

[sdlime]

The function getResult() was unaffected by the single-pass stuff as was the composition of the resultCache so the approach should still work. It would be easier to just call layer.getNumResults() though.

Must be failing in the queryByShape() function some how. I agree on fixing now and will take a look this evening. I see at least some tests worked...

Steve

[sdlime]

Hi Frank: Was looking into this tonite. I verified that the correct shape is getting to the msRasterQueryByShape() and that the correct shape bounds are passed on to msRasterQueryByRect(). Turning on debugging I get the following:

[Wed Oct 21 22:46:16 2009].177771 msRasterQueryByRect(grey): entering.
[Wed Oct 21 22:46:16 2009].178901 /Users/sdlime/msautotest/gdal/data/data/tile11.vrt: Image handling error. Unable to open file grey for layer `/Users/sdlime/msautotest/gdal/data/data/tile11.vrt' does not exist in the file system,
and is not recognised as a supported dataset name.
 ... fatal error.
msRasterQueryByRect()

The 'data/data' in the path is a problem. If there's no SHAPEPATH then it looks like the tiles in the tile index are interpreted as being relative to the location of the tile index (see ~line 780 in maprasterquery.c). In this case they're in the same directory.

I edited the tileindex.map file and set a SHAPEPATH and it worked (55 results as expected). Better solution is probably to fix the tile_index.shp file and remove the leading 'data/' from each file location.

In past versions (pre-5.4 at least) I think the tile location was interpreted relative to the mapfile. Another fix would be to test relative to the tile index location and if that doesn't work then try relative to the mapfile location.

Let me know what you'd like to do and how I can help.

Steve

[warmerdam]

Thanks Steve, I'll take care of it from here.

I had a vague sense that path handling with raster tileindex might have changed, but I hadn't realized it was likely to break old/existing tileindexes. This doesn't seem great. I wonder if it is something particular to the raster query code, which I gather from #3109 does not utilize the general raster tileindex mechanism.

[sdlime]

Might be nice to have a msGetTileFilename() function that all the various tile handling pieces could use. The rules should be the same everywhere.

Steve

[warmerdam]

Updated tileindex to use path relative to tileindex instead of map (r9501).

Fixed a few issues in raster query introduced as part of #3168 "maxresults" work (r9502).

raster query test now passing.

I have confirmed the raster query filename processing is now in line with regular raster layer filename processing, so no action is required here. It is unlikely that any real users will run into the path quirk with regard to raster queries that the test script encountered.