Hi Milton,
I'm doing some preliminar tests with your sample data.
I have also fixed a missing import which prevented some EPSG code parsing.
Here below, some feedbacks.
On Wed, Oct 15, 2008 at 12:56 PM, Milton Jonathan <[EMAIL PROTECTED]
> wrote:
> 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
I guess I have applied the same workaround. Did you simply changed the
DirectEpsgFactory and AbstractEpsgFactory code (fixing the Unit for 9108)?
I have some issues in reprojecting SAD69.
>
> <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/<http://www.tecgraf.puc-rio.br/%7Emilton/>
>
> So, what I got was this:
> - URUC_UTM63_WGS84.ecw: result was all black (!) with or without JAI
Worked fine for me without JAI.
>
> - URUC_UTM63_WGS84.sid: infinite loop with JAI, OK without JAI
Worked fine for me 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
Anyway, whenever you use direct access (I mean without using JAI-ImageRead)
while reading the whole dataset, the reader will try to load all the
requested data at once.
Therefore you may get an OutOfMemoryException unless you set a bigger amount
of heap space with the -Xmx option.
More results will follow...
Regards,
Daniele
>
> 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
>
--
-------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer
GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267
http://www.geo-solutions.it
-------------------------------------------------------
-------------------------------------------------------------------------
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
