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. The trouble for me now is that there's a lot of code in there, some of which I can not find the source code for (PlanarImage) and so it's hard to see where the wrong data is making its way in to the array of doubles that actually holds the raster data. It seems to be an off-by-one error (I get the pixel value for the pixel in the x-1 column) that maybe only gets triggered perhaps in a cache miss/hit case? Any clues? I'm seeing if I can get permission from the customer to share the image with you so you can see it for yourselves, but in the meantime here's some code with a broken/workaround switch: https://paste.dollyfish.net.nz/e0b13a?filetype=java I'm guessing that unless the source of the problem is in either the geotools or jai-ext code, fixing this is going to be hard... Cheers, Nick -- Nick Griffiths Catalyst IT - Open Source Technologists +64 4 897 7457 | ni...@catalyst.net.nz | www.catalyst.net.nz _______________________________________________ GeoTools-GT2-Users mailing list GeoTools-GT2-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users