Martin Tomko ha scritto: > Hi guys (Andrea *2, Michael ) > thanks for the hints. Indeed, the GridGeometry2D approach will not help > my case, but a similar approach should be somehow possible. > > IN fact, if it was possible to read the current envelope of the geotiff > in without the actual raster data, do the cropping operation and return > a meaningful return envelope, and only read parts of the raster in it > would be great. > > Thanks for the pointer to the cropping operation, I do something similar > now, although it still requires having the whole original GridCoverage2D > in memory...:
I think there is some misconception here. If your original coverage is stored as a single big bad block (e.g., a png/jpeg file, or an untiled tiff) it has to read fully in memory no matter what. Otherwise the reader will just read up the minimum portion needed, and will do so by building a JAI chain, meaning tiles are read on demand, not up front. So if your input format is setup for efficiency, memory usage will be limited, if it's badly layed out instead everything will be read into memory and there is really nothing that can be done to avoid it. That's why cropping is not part of the readers, it's an operation that's generic, no sense in putting it into all readers. What's not generic is choosing the right overview, subsampling and accessing the right tiles: all readers will do that efficiently if they can (and if you pass down the proper hints). Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
