Hi, thanks for your response. I understand the drawbacks of changing the current architecture. What about the following with respect to Geo-Tiffs and org.geotools.gce.geotiff.GeoTiffReader: Make the function getHRInfo protected instead of private to allow subclasses to override. Or maybe refactor getHRInfo that file access to projection and world file are separated into two distinct protected member functions also to allow overriding. Another idea: allow for the field raster2Model to be provided with the hints as a third option beside parseWorldFile. These changes would not have any drawback to performance in existing installations. However, one could provide the tif-file as stream and all other data as pre-read hints. A generic stream provider would be good: I use Geotools in an OSGI environment and access resources via OSGI interfaces. Thank you Michael Andrea Aime wrote on Sunday, April 15, 2012 5:48 PM
_____ On Fri, Apr 13, 2012 at 8:24 AM, Michael Gruebsch <[email protected]> wrote: Hi, in an application I use geographic data which should not be disclosed as raw data. That is the data should be processed and displayed by the application but should not usable if extracted in binary form. The idea is to encrypt the data and decrypt it on the fly. However, the readers I have to use (GeoTiffReader and ShapefileReader) expect in it's most common usage scenario that the data exists as files. This disallows encryption because there is no way to intercept. For example: There are the three files .tif/.tfw/.prj. Although one can supply the .tif as stream and .prj as hint, it is impossible to supply the world coordinates .tfw as an object other than file. Is there any way to meet the requirement for non-disclosure of raw data? Hmm... hard call I fear. The Shapefile data store should be able to read shapefiles from within a jar in the classpath, so it has at least some allowance to work off streams (though it will be very slow if you do that), but one that is pretty much geared towards reading from the classpath. I guess some work would have to be done to make it able to read from a generic stream provider (not a stream, something that can repeatedly return a stream for each read operation, like URL does). The raster reading code really needs a file instead, that would also require quite a bit of modifications and again some sort of stream provider. A generic provider could be built on top of commons-vfs I guess: http://commons.apache.org/vfs/filesystems.html Anyways, not a small amount of work, and we'd have to be certain that whatever is done to increase generality does not hurt one bit the performance in the case direct filesystem access. Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf -------------------------------------------------------
------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________ GeoTools-GT2-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
