On Thu, 7 Jan 2021 at 18:54, Lorenzo Di Giacomo <loridi...@gmail.com> wrote:
> Thanks Ian, yeah i removed the print on the awt rectangles that i get > from ( getGridGeometry().getGridRange2D().getBounds() ). > Also, that difference is visible in plannarImage. > I was wondering if that difference in data after serialization / > deserialization is "normal" and could affect the writing operation. > Because basically what happens is: > 1) Read an image in GridCoverage2D > 2) Cut in N parts using Crop operation ( getting N GridCoverage2D ) > 3) Serialize each part and send it > 4) Deserialize each part > 5) Merge them back (with the result of 1 GridCoverage2D) > 6) Write the GridCoverage2D in file.tiff > > Now all this works just fine and is also really fast even with a lot > of cuts, since i merge them back in multithreading using the MapReduce > paradigm with ForkJoin. > But ... When there are few cuts (< 200/300) it's fine, but with 2000 > cuts, for examples, it's stuck on writing. > Doing the steps above (without points 3,4) write the file well. So i > was wondering if it could be that difference on X and Y, if it could > affect the write operation. > I also tried on a powerful server ( octa-core and 24gb RAM ), thinking > could be of a memory issue, but i get the same result. > Thanks for your suggestions! > I think this makes sense, when you have a subset of a larger image the gridGeometry "knows" it position relative to the origin of the full image, but when you read it back in it has no larger context so it's origin has to be 0,0 - I think the solution is to make the merge in geographic space not pixel space or encode the pixel image origin in with the image data. Ian
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
