Hello Simone, Thanks for your reply and sorry for the delay in answering.
OK, I tested your solution, and it works fine in general terms. However, I am still getting a lot of unusual behavior when trying to reproject different formats in different reference systems. Some of these problems may be related to issues in the referencing module (which I guess Martin is currently cleaning up), especially when working with the SAD69 datum (the EPSG standard thinks you should define units in weird DMS units - which is usually not the case). But first, I'd like to apologize: the sample I specified on the previous post was not properly georeferenced! Sorry! So, this time I tested things a little more systematically. I tested resampling all images to EPSG:4326 (WGS84, geographic), using JAI (if possible) and not using JAI. To be able to work with SAD69, I needed to follow Martin's suggestion to workaround the DMS unit problem. See: http://www.mail-archive.com/geotools-gt2-users@lists.sourceforge.net/msg05860.html Also, I needed to set Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER to true to get things to work (I will talk more about that in a separate post). OK, so let's go to the tests. Everything worked fine for a GeoTIFF image in WGS84/UTM, but problems showed up when testing the following 3 different sets of images: 1. URUC_UTM63_WGS84 (WGS84 datum, UTM projection) - ECW and MrSID 2. GUANABARA_UTM23_SAD69 (SAD69 datum, UTM projection) - TIFF and MrSID 3. N_GEOG_SAD69 (SAD69 datum, geographic) - ECW I have made these samples temporarily available at: http://www.tecgraf.puc-rio.br/~milton/ So, what I got was this: - URUC_UTM63_WGS84.ecw: result was all black (!) with or without JAI - URUC_UTM63_WGS84.sid: infinite loop with JAI, OK without JAI - GUANABARA_UTM23_SAD69.tif: (no JAI available) OK but *really* slow - GUANABARA_UTM23_SAD69.sid: works with JAI but result has completely wrong georeferencing, not enough memory without JAI - N_GEOG_SAD69.ecw: big file - takes long but works with JAI, not enough memory without JAI So, if you find time to test out these issues.. I'd really appreciate it! Thanks a lot, Milton PS: the code I used was basically the following (using v 2.5-RC1) - please let me know if I'm doing something stupid or not recommended here: --- Hints hints = new Hints(); hints.put(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER, true); GeoTools.init(hints); File file = new File("D:\\data\\source.sid"); File destFile = new File("D:\\data\\dest.tif"); AbstractGridFormat gridFormat = (AbstractGridFormat)GridFormatFinder.findFormat(file); if (gridFormat instanceof UnknownFormat) throw new FactoryException("Cannot find a reader for file " + file); GridCoverageReader reader = gridFormat.getReader(file, hints); GridCoverage2D coverage = null; if (gridFormat instanceof BaseGDALGridFormat) { ParameterValue<String> tilesize = (ParameterValue<String>) BaseGDALGridFormat.SUGGESTED_TILE_SIZE.createValue(); tilesize.setValue("512,512"); ParameterValue<Boolean> useJaiRead = (ParameterValue<Boolean>) BaseGDALGridFormat.USE_JAI_IMAGEREAD.createValue(); useJaiRead.setValue(true); ParameterValue<Boolean> mt = (ParameterValue<Boolean>) BaseGDALGridFormat.USE_MULTITHREADING.createValue(); mt.setValue(true); coverage = (GridCoverage2D) reader.read(new GeneralParameterValue[] { tilesize, useJaiRead, mt }); } else { coverage = (GridCoverage2D) reader.read(null); } CoordinateReferenceSystem targetCRS = CRS.decode("EPSG:4326"); GridCoverage2D coverageTransf = (GridCoverage2D) Operations.DEFAULT.resample(coverage, targetCRS); GeoTiffWriter writer = new GeoTiffWriter(destFile); writer.write(coverageTransf, null); --- Simone Giannecchini wrote: > Ciao Milton, > I downloaded and checked your image. A few annotations: > > - here is part of the gdalinfo > > > This means, 3 bands, size 8k*8k at the highest res with tiling of 1024*128. > By default the Imageio-ext gdal plugin does not use JAI ImageRead but > tries to do a full read using the ImageReader. > The error you are seeing is the underlying JVM running out of direct > memory (fast native mapped heap), see here [1] for reference. > > If you want to be able to read and reproject larger raster through > imageio-ext with low memory footprint. You can do something like this: > > 1> retiling on read to have better tile size > 2> use JAI ImageRead instead of doing a plain read on the ImageReader > 3> use multithreading capabilities of our ImageReader and our > ImageReadMT operation. You can control the number of tile through > JAI.getDefaultInstance().getTileScheduler().setParallelism(numTile); > > With the above setting I have been able to reproject the image with > these low footprint settings : > -XX:MaxDirectMemorySize=8M -Xmx16M > > Ciao, > Simone. > -- Milton Jonathan Grupo GIS e Meio Ambiente Tecgraf/PUC-Rio Tel: +55-21-3527-2502 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
