Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] RFC : native support bundles for java advanced imaging
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 <daniele.romagnoli@xxxxxxxxxxxxxxxx>
Hi Jody,


On Thu, Jan 5, 2012 at 2:08 AM, Jody Garnett <jody.garnett@xxxxxxxxx> 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:


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?





--
-------------------------------------------------------
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


-------------------------------------------------------


Back to the top