comments inline .. BTW, just pushed the initial jai_imageio bundles to my repository : https://github.com/fgdrf/udig-platform/commit/c61feb753abc02dbaa148e0daaeac14d70a1e9b3 (jai branch). To test this bundles, add the javax.media.jai_imageio bundle to required dependencies of net.refractions.udig.libs and reexport this dependency. Check in jre settings, that the jai jars are not loaded from runtime, If you are not sure hoe to do this, add an other JRE to your eclipse and use this to start udig.product. I also closed the two projects - net.refractions.udig.jai and - net.refractions.udig.jai.macosx
and removed the relevant sections in udig_platform-feature feature.xml and added the new bundle javax.media.jai_imageio instead. Feedback is warmly welcome! -Frank 2012/1/5 Daniele Romagnoli <[email protected]> > Hi Jody, > > > On Thu, Jan 5, 2012 at 2:08 AM, Jody Garnett <[email protected]>wrote: > >> - the JRE is still required for the gdal libraries >> >> Perhaps not? As long as the environmental variables are set correctly >> (which is what we use the udig.bat or udig.sh script for) the JRE should be >> able to link in those libraries ... >> >> Indeed to set up a development environment that uses GDAL we depend on >> developers setting those global environmental variables do we not? >> >> Let us quickly ask Daniele on this one :-) >> >> Daniele we (well Frank) has been able to package up some of the JAI and >> ImageIO jars into bundles so they show up on the class path when we are >> running GeoTools code. >> >> Is there a way we can set up the execution environment when we run uDig >> so that the java executable can see the various gdal native libraries? >> Right now we copy them into the JRE bin folder. >> > Setting the LD_LIBRARY_PATH or java.library.path should work fine. > > >> >> Frank also had a number of questions you may be able to answer: >> >> Now I have several questions before I request a pull for udig-platfrom: >> 1. How can I check, whether the native libraries are loaded correctly >> (API calls, something like isNativSupportAvailable()) >> >> You can call > it.geosolutions.imageio.gdalframework.GDALUtilities.isGDALavailable() > > Thanks for that!!! Will try this. > 2. Where can I find additional data sets to test, whether everything works >> correctly with JAI/imageio >> I tested with mentioned asc files and tiff files -> everything looks >> fine (on mac) but it was not possible to load *.sid and *.ecw files -> Add >> data wizard doesn't finish, no exceptions, Any suggestions here? >> >> You could take a look on the test-data folders of the gdal plugins > provided by imageio-ext. > https://svn.java.net/svn/imageio-ext~svn/branches/1.1.x/plugin/gdal/ > > once you have selected a plugin (like gdalecw) go inside > src/test/resources folder and go down through the package hierarchy to the > test-data folder > (as an instance, > > https://svn.java.net/svn/imageio-ext~svn/branches/1.1.x/plugin/gdal/gdalecw/src/test/resources/it/geosolutions/imageio/plugins/ecw/test-data/sample.ecw > ) > > Hope this helps. > Regards, > Daniele > > >> 3. Could anybody test if I created the pull request the native libs on >> linux 32/64 bit, I can test on mac os and win32/64 bit with 32 bit runtime >> 4. Is there a wiki page that describes how to setup the JRE with gdal >> binaries for native support? >> >> Frank one of the best resources is the ImageIO-EXT Documentation: >> - http://java.net/projects/imageio-ext/downloads/directory/Documentation >> >> >> Indeed the README.txt has the following: >> >> ======================= >> ImageI/O-Ext Deployment >> ======================= >> >> 1. Make sure all the imageio-ext jars you need are on the classpath of your >> application >> >> 2. Download the proper GDAL Native libraries (depending on your System) >> and extract them on your disk. >> >> 2a. If you are on Windows, make sure that the GDAL DLL files are on your >> PATH (by adding >> an entry to the PATH environment variable referring to the folder where >> the native libs >> have been deployed). Note that multiple DLLs versions available on >> different location on your >> PATH's machine may cause loading issues. Usually, you can extract DLLs on >> your JDK/bin folder. >> When done, you could run "gdalinfo --version" to check the native libs >> installation. >> >> 2b. If you are on Linux, make sure to set the LD_LIBRARY_PATH environment >> variable >> to refer to the folder where the SOs have been extracted. >> (Typical uses are extracting SOs on your java JDK in the /jre/lib/i386 >> (Linux32) >> or /jre/lib/amd64 (linux64) subfolders). >> When done, you could "cd" to the folder where they have been extracted and >> run >> "./gdalinfo --version" to check the native libs installation. >> >> 3. Download the GDAL CRS Definitions zip archive and extract them on your >> disk. >> Make sure to set a GDAL_DATA environment variable to the folder >> where you have extracted the files. >> >> >> Based on that I think we could modify either our udig.at or udig.sh >> script; or mess around with the ini file (for example the java library >> path). >> >> However a bit of research indicates that we may be able to do this using >> the normal eclipse mechanism (i.e. allow it to build the library path). I >> think you are already using this technique? >> >> >> http://stackoverflow.com/questions/957700/how-to-set-the-java-library-path-from-eclipse >> >> > > > -- > ------------------------------------------------------- > Ing. Daniele Romagnoli > GeoSolutions S.A.S. > Software Engineer > > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584 962313 > fax: +39 0584 962313 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.youtube.com/user/GeoSolutionsIT > http://it.linkedin.com/in/danieleromagnoli > > > ------------------------------------------------------- > >
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
