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


> 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

Reply via email to