Ciao Simone, for the code there is obviously no problem (I took it from the MapViewer), but the data are not my own, so I can't make them freely usable. Anyway I find it a good idea to supply it as example, thanks to you for the help.
The code like it is now works really on a nice way and is usable as a small rendering application :) There is only the need to play around a bit with tiling and compression (I got some various errors on that geotiff with LZW and deflate compression). At the moment I'm playing around with a: "The provided envelope is outside the source CRS definition area" error I get and am not able to track down. I've seen that there is a post of last november talking about it, but no solutions. I think soon I will post my situation to the list. :) Bye Andrea Simone Giannecchini wrote: > Ciao Andrea (actually both of you :-) ), > sorry but these days we are busy to death. > > I have refactored a bit the code and preprocessed a bit the supplied > image and it works very quickly (as Andrea Antonello can confirm). > > A few remarks: > > 1>Remember that the JMapPane is not a component implemented for > super-fast super-optimized rendering but it is an extension to get > people started with rendering. > > 2>When you have a big raster (big > 50 mb) you are supposed to used a > tiled format and to add overviews. You can use gdal for doing this or > you can wait a bit and use the tools that me and Andrea Aime are > putting out for GeoServer 1.5. > > 3>Once your coverage has been prepared if you want to show it real > quickly you have to pass the MapContext the > AbstractGridCoverage2DReader, you don't have to create the > GridCoverage2D and pass that to the context because this way you won't > be able to leverage on overviews. Reason is that once you create a > GridCoverage2D you ALREADY have an image hence downsampling means > subsampling the highest resolution image on the fly! If you supply the > MapContext with an AbstractGridCoverage2DReader subclass the > StreamingRenderer will use this reader to select the best fitting > coverage from the various available resolutions which would mean A > HUGE difference in performances. Even if you do not have overviews, > using a reader is still beneficial since I also implemented decimation > on loading which means even if I do not overviews, in case a low res > coverage is requested I try to selectively load only the part of the > data needed (which will cause faster operations afterwards). > > > Just to give an example, The tiff that Andrea Antonello was providing > was a compressed CCCFAXsomethign B/W tiff which uncompressed rgb was > like 200mb while compressed was only 2MB. Moreover no tiling and no > overviews. > > Now if you create a GridCoverage2D from it and you start zooming in > and out you will be decompressing and scaling it on the fly which will > be extremely slow and extremely memory consuming (hence the OOM > errors). > > > > 4>This is related to the provided data. This tiff is an ugly 1bit > (B/W) compressed tiff so when you will be zooming out do not expect to > see much details beyond some strange black artifacts :-). > > > <<Conclusion>> > I gave Andrea Antonello the refactored code along with the > preprocessed data and he seems to be pretty happy about it. > > What I would like to ask him is, do you mind if we share this code as > a tutorial or example along with the data you provided? If you have > concerns with the provided data, can I use just the code and provide > some big geotiff myself? > > I think it would give people the possibility to easily understand how > to use the latest improvements for coverages in gt 2.3. > > > What do you think Andrea (Antonello). > > Regards, > Simone. > > > > > On 1/25/07, Andrea Aime <[EMAIL PROTECTED]> wrote: >> Andrea Antonello ha scritto: >> > Fine, at least I'm not getting crazy. >> > >> > I tried your gdal_translate solution and in fact it works well. >> > >> > There is only one problem, which I already noticed also with the world >> > image files. If I zoom in once or twice I get the following exception: >> > >> > Error: One factory fails for the operation "FilteredSubsample" >> > Occurs in: javax.media.jai.ThreadSafeOperationRegistry >> > java.lang.reflect.InvocationTargetException >> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> > at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> >> > at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> >> >> Andrea, unfortuntely this stack trace is not very informative, we would >> need to unpack the invocation target exception cause to understand. >> Do you have a working and self contained example I can use? >> Cheers >> Andrea >> > > -- ____________________________________________________________________________ HydroloGIS - Environmental Safety Modelling www.hydrologis.com Andrea Antonello Environmental Engineer mobile: +393288497722 "Let it be as much a great honour to take as to give learning, if you want to be called wise." Skuggsja' - The King's mirror - 1240 Reykjavik ____________________________________________________________________________ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
