OpenJUMP et l’accès aux bases de données
Il existe de nombreux plugins pour accéder aux bases de données. La version JUMP de base contenait déjà une api d’accès aux bases de données en lecture seul qui n’était pas encore activée (datastore).
Depuis la version 1.2 d’OpenJUMP (2007), le code est activé (menu couche>ajouter une couche à partir de la base de données et couche>exécuter une requête). De plus le plugin PostGIS d’Uwe Dalluege est maintenant présent dans la distribution standard.
| SGBD | Nom de l’extension | E/S | Auteur | Version/Date | en savoir plus |
|---|---|---|---|---|---|
| Postgis | Inclus dans OpenJUMP | Lecture | Vividsolutions | 2005 | Plus |
| PostGIS | PostGIS plugin | Lecture Ecriture | VividSolutions Uwe Dalluege | version 1.3.1a 2010-04-24 | Plus |
| PostGIS/Oracle | SISDB PlugIn | Lecture | Paolo Rizzi | version 0.2 2007-05-16 | Plus |
| ArcSDE | ArcSDE PlugIn | Lecture ? | Larry Becker | version 2.0 2006-08-30 | |
| Oracle Spatial/MySQL/PostGIS/SpatiaLite | JUMP DB Query PlugIn | Lecture | Larry Reeder | Version 0.7.2 2010-06-27 | Plus |
| SpatiaLite | spatialliteplugin | Lecture | ??? | Version 1.3 2010-02-11 | |
| H2 | Plus |
vividsolutions datastore api : l’api datastore de vividsolutions a été ajoutée à JUMP en décembre 2005. Elle a été activée dans OpenJUMP en 2007. Le format de stockage de la géométrie a été changé de WKT en WKB dans la version 1.2.0C d’OpenJUMP pour s’adapter aux nouvelles versions de PostGIS (format WKB privilégié par rapport au format WKT depuis PostGIS 1.0).
L’interface de connexion d’OpenJUMP à une base de données est très simple. Le seul pré-requis est la présence dans le classpath (ou dans le répertoire JUMP_HOME/lib/ext) d’un driver jdbc adapté à la base de données interrogée. On a ensuite la possibilité d’interroger une table avec ou sans condition attributaire, charger les données ou les afficher en dynamique, et possibilité de faire des requêtes SQL complexe.
Les demandes d’amélioration en cours pour cette API sont :
Prise en compte des SRID (actuellement, les SRID sont ignorés) Possibilité de visualiser des VUES plutôt qu’uniquement des tables (dans l’option dynamique) Possibilité d’accéder à la base de données en écriture (amélioration plus lourde)
PostGIS plugin : Ce PlugIn est complètement indépendant de l’infrastructure d’accès aux bases de données développé par vividsolutions (voir ci-dessus). Ses principaux atouts sont :
- de bien marcher
- de permettre d’accéder à la base en écriture (créations/suppressions/modifications)
- de gérer les SRID (identifiant du système de référence) Je n’ai pas vraiment testé 2 et 3.
Principal défaut : les données sont entièrement chargées en mémoire (pas possible de charger une grosse table) et il n’y a pas moyen d’effectuer une requête SQL qui permettrait de récupérer une petite partie des données seulement.
SISDB with Oracle and PostGIS : Ce plugin, développé par Paolo Rizzi, utilise la même interface que le plugin de vividsolution intégré a OpenJUMP (accès par le menu couche > ajouter une couche à partir de la base de données ou couche > exécuter une requête...). Le plugin enrobe une api pré-existante d’accès aux bases de données développée par P. Rizzi. Elle est par conséquent un peu plus lourde que l’api de base (celle de vividsolutions).
Avantage : le plugin marche du premier coup. Il permet en principe d’accéder à une base Oracle Spatial (non testé). L’auteur envisage d’ajouter des fonctions d’accès aux données en écriture...
Inconvénient : comme l’api de vividsolutions, le plugin permet d’accéder aux données en lecture seul. Un bug empêche actuellement de récupérer les champs varchar qui ne précisent pas de longueur maximum (le bug, signalé à l’auteur, devrait être réparé dans la prochaine version).
JUMP DB Query Plugin : Ce plugin permet de se connecter à 4 types de bases de données différentes. Je n’ai actuellement testé que la connexion à PostgreSQL/PostGIS qui marche bien. Pour récupérer les différents drivers permettant de se connecter à chaque type de base, lire les instructions sur la page du projet. Le plugin n’est pas internationalisé et l’interface de connexion est moins conviviale que l’interface standard. Il permet d’écrire une requête libre sans transtyper l’attribut geometry en (ex. select my_geom, nom, nombre from my_table), mais souffre probablement d’autres limitations (select my_geom,* from table n’a pas marché).
RSS 2.0