Thanks Andrea, I really don't know enough how the mechanisms work behind the scenes, hence my question. I understand that if you have a tiled source of coverage, only the relevant tiles can be read. (btw, I only played with tiled tiffs a long time ago - would have been 2.4 or so, and had troubles. Is there a nice snipped of code available somewhere, showing how to start with the GeoTIFF reader and an index shapefile?)
But is it really so that there is no way to read in only the appropriate portion? Imagine a tiff+world fiel, or a geotiff - IFF we could read just the "metadata", we can reconstruct the Envelope (in the latter case even referenced envelope), and do an intersect operation with any other envelope, for instance coming from a geometry. The result of the intersection could then be transformed into the grid coordinates of the coverage (knowing the dimensions and the starting pixel), and only read these in, with the new envelope set. As I said, I have limited knowledge of the current technology behind the scenes, but am happy to help if there is any way I can be useful. Apologies for this naive approach, just trying to think how to go about it. Cheers Martin On 5/5/2010 9:57 AM, Andrea Aime wrote: > 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 > > > ------------------------------------------------------------------------------ _______________________________________________ Geotools-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
