Thanks for the tip! Il ven 8 gen 2021, 10:37 Ian Turton <ijtur...@gmail.com> ha scritto:
> > > 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
