Emballage GDAL avec Java

Question

J'ai un projet Java qui utilise des liaisons GDAL sur Win7. Le problème est que, en raison de la nature des liaisons, il est nécessaire de définir des variables d'environnement pour fonctionner, en particulier PATH, GDAL_DATA, GDAL_DRIVER_PATH et PROJ_LIB. Je veux dire qu'ils sont assez faciles pour moi de créer et de pointer vers le répertoire GDAL. Cependant, si jamais je veux distribuer cela, cela va être une étape difficile pour l'utilisateur moyen.

J'ai besoin d'un moyen de configurer les liaisons GDAL de telle sorte que l'utilisateur puisse copier le programme où il veut, avec les bibliothèques jar et GDAL, et le code bootstrap va automatiquement définir GDAL pour trouver ces variables Localisation actuelle.

Maintenant, j'essayé ce qui suit (qui utilise une partie d'une solution posée dans une question similaire: package GDAL JAVA Binding and native library in a SWT plugin):

// define `root` before to grab the path of the where the JAR is located 
// bit of a hack-y way to set the classpath 
System.setProperty("java.library.path", root+"gdal"); 
Field fieldSysPath = ClassLoader.class.getDeclaredField("sys_paths"); 
fieldSysPath.setAccessible(true); 
fieldSysPath.set(null, null); 
// set these gdal config variables programatically 
gdal.SetConfigOption("GDAL", root + "gdal"); 
gdal.SetConfigOption("GDAL_DATA", root + "gdal\\gdal_data"); 
gdal.SetConfigOption("GDAL_DRIVER_PATH", root + "gdal\\gdalplugins"); 
gdal.SetConfigOption("PROJ_LIB", root + "gdal\\proj_lib"); 

Mais il échoue dans la première SetConfigOption() avec l'erreur suivante:

Native library load failed. 
java.lang.UnsatisfiedLinkError: C:\...\gdal\gdaljni.dll: Can't find dependent libraries 

Ce qui signifie au moins que la première partie fonctionne parce qu'elle localise correctement gdaljni.dll, mais il semble que avant que le SetConfigOption() puisse faire son travail, il essaie déjà de regarder dans ces chemins juste pour initialiser et échouer.

Maintenant, si je règle manuellement les variables d'environnement, cela fonctionne bien. fixations

GDAL de: http://www.gisinternals.com/

Answer 1

Je suis désolé de ne pas fournir une réponse spécifique à Windows, mais les concepts entre Unix et Windows ici sont fondamentalement les mêmes. L'erreur que vous rencontrez est due au chemin de la bibliothèque (dans Windows, toujours la DLL binaire) ne faisant pas partie des chemins requis. Les paramètres de configuration GDAL ne gèrent pas la route vers la DLL, mais plutôt les emplacements vers les données internes.

Cela peut ne pas être la meilleure solution, mais cela a très bien fonctionné pour moi dans le passé. La clé consiste à créer un script qui met à jour le chemin requis pour démarrer l'application.

Dans le script, vous devez ...

1. obtenir le répertoire du script lui-même de sorte que vous pouvez lancer l'application depuis n'importe où sur le système.
2. Ajoutez le chemin d'accès à votre bibliothèque dans la variable d'environnement appropriée. Utilisez le SCRIPT_PATH comme base du chemin.
3. Mise à jour DYLD_LIBRARY_PATH (Mac), LD_LIBRARY_PATH (Linux), et si je me souviens, PATH (Windows).
4. Démarrez l'application comme vous avez exporté le chemin d'accès à la bibliothèque à l'aide de la variable SCRIPT_PATH comme base.

Voici un exemple où je n'ai pas mis le rpath en clang sur mon Mac.

• package

  • bin/foo
  • lib/libtest.dylib
  • run.sh

Exécuter le script

#!/bin/sh 

# Get the directory of this script being run 
SCRIPT_PATH="`dirname ${BASH_SOURCE[0]}`" 

# Export the Path 
export DYLD_LIBRARY_PATH=$SCRIPT_PATH/lib:$DYLD_LIBRARY_PATH 

# Run the executable 
$SCRIPT_PATH/bin/foo