On 18/09/18 22:40, Nick Griffiths wrote: > > On 18/09/18 16:27, Nick Griffiths wrote: >> Hi again list, >> >> I've noticed that a medium sized raster (.asc) produces inconsistent >> results when sampling pixels. It looks like I am getting the pixel to >> the left of the one I should be getting, but this behaviour is >> consistently inconsistent (in that it always occurs with the same set of >> points being sampled, but I can't discern a pattern) and it goes away if >> I reopen the grid coverage between samples (which is awfully slow, but >> produces correct results) >> >> I've got it down to a very small reduced test case that reflects the >> image field from the GridCoverage2D and them pulls two pixels out from >> different tiles. If I reopen the gridcoverage between the samples, it >> gets the right values. If I don't, it doesn't. >> >> I've converted the source data to tiff using gdal_translate and I get >> the same results, which tells me it's probably not the file format. > > Seems like my gdal_translate didn't work as expected - after correctly > transforming the raster to a tiff, I now find the issue only occurs with > the original asc file and not the tiff. > > So perhaps this is an issue with the AsciiGridsImageReader?
I think I might have found something with the asciigridsimagereader. It looks like it's to do with the tile marker cache being used to find a good spot to start seeking from. 1) In the case of freshly created grid, the tile marker cache is empty, and so we are forced to seek through the entire file to find where to start looking, and the reader returns the right set of values. 2) In the case of an adjacent tile look up, the tile marker cache gives us an exact match and correctly lines up the input stream at the right position. The reader returns the right set of values. But in the case of the nearest lower key found in the marker cache, things can go awry. I can see that the skipping code in this instance seems to put is in at the wrong position. Given that case 1) works, which uses the same skipping code, I must assume that the marker cache is returning the wrong result here (possibly either the wrong sample position or the wrong seek position?) or is being misused in a way that results in derived results being poisoned? I can sort of prove this by filling the tile marker cache by iterating through the tiles, so that the marker cache is filled with all the correct positions. Random access after this works correctly. So I have a workaround, which is to access the image directly first and iterate through all the tiles in order, which should populate the marker cache correctly - but this is deeply unsatisfying and I may sink a little more time in to figuring out how the tile marker cache ends up in such a broken state when it is accessed in a non-continuous way like that. Cheers, Nick _______________________________________________ GeoTools-GT2-Users mailing list GeoTools-GT2-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users