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

Reply via email to