GeoKettle est une version enrichie de Kettle (PDI) incluant des fonctionnalités propres lui permettant de manipuler de l’information spatiale. L’objet de cet article est de présenter les fonctionnalités globales de l’outil et d’en faire ressortir les avantages et limites.

# Les fonctionnalités

En plus des fonctionnalités proposées nativement par Kettle et sur lesquelles nous ne reviendrons pas (consulter Sylvain, le spécialiste BI d’Atol pour plus d’infos !), GeoKettle apporte :

Un nouveau type de données « geometry » en plus des types (integer, string, etc.) déjà présents dans Kettle. A la prévisualisation des données, les géométries sont visibles dans leur représentation textuelle Well Known Text (POINT, LINESTRING, POLYGON, etc.) en attendant le « viewer carto » annoncé.Ce type « geometry »est exploitable lors des étapes d’extractions ou d’alimentation depuis ou vers les SGBD Oracle, Postgresql / Postgis / Mysql sans aucune manipulation spécifique (La liste des SGBD supportés devrait par ailleurs s’enrichir prochainement).

De nouvelles étapes dédiées au « GIS » et regroupées dans la catégorie « Geospatial »

• GIS File Input : cette étape permet d’extraire les informations géographiques et attributaires à partir d’une couche ESRI Shapefile (fichiers shp, shx et dbf). Le nom du champ géométrique par défaut est « the_geom ».
• GIS File Output : cette étape permet de générer une couche ESRI Shapefile à partir d’un flux de données contenant notamment un champ de type « geometry ». Si plusieurs champs de type « geometry » sont présents, il faut au préalable passer par une phase d’altération pour sélectionner celui à exporter.
• Set SRS : cette étape permet d’affecter un système de projection cartographique à un champ de type « geometry ». Le code affecté se base sur la liste EPSG mais il est possible de définir sa propre chaine de projection au format WKT. Cette étape est impérative lors d’un import en SGBD spatial dès lors qu’une contrainte sur le système de projection est présente et que le système de projection source associé à la géométrie est inconnu. Elle permet également de de créer le fichier de projection (prj) adéquat lors d’une étape « GIS File Output ». Ce dernier est exploitable par les outils SIG bureautique courants.
• SRS Transformation : cette étape permet de transformer une géométrie d’un système de projection vers un autre. Lors des tests, les résultats pour la transformation du système Lambert 2 Etendu vers le système WGS84 n’ont pas été concluants… Mauvaise manip ?

La modification d’étapes existantes par l’ajout d’opérateurs d’analyse spatiale tels que GIS_INTERSECTS, GIS_EQUALS, GIS_CONTAINS, GIS_CROSS, etc. pour réaliser les opérations de types, « A intersecte B », « A traverse B », etc. Ces opérateurs sont notamment disponibles dans les étapes « Filtrage lignes » et « Produit cartésien ». En terme d’utilisation, les étapes de filtrage de lignes pourront par exemple être utilisées pour effectuer des requêtes spatiales entre fichiers ESRI Shapefile tandis que le produit cartésien permettra de limiter le nombre d’itérations en amont d’une étape de « geoprocessing ».

La possibilité d’exploiter les fonctionnalités de Java Topology Suite (JTS) à travers l’étape « Exécution Scripts Java ». Cette possibilité s’avère intéressante puisque elle permet de tirer partie des opérateurs de construction ou de modification de géométries (effacer A par B, intersecter A et B, fusionner A et B, créer une zone tampon autour de A, etc.) ou d’interroger les propriétés des objets (aire ou périmètre d’un polygone, coordonnées du premier point d’une ligne, etc.). Si les possibilités sont riches, l’utilisation de ces fonctionnalités nécessite de connaitre au minimum les objets, méthodes, etc. offerts par JTS. Cette connaissance s’avère parfois nécessaire, notamment pour effectuer certaines agrégations sur les géométries (l’équivalent du « geomunion » de PostGIS !), l’étape « Agrégation valeurs » de la catégorie statistique n’intégrant pas de fonction «Dissolve» aux cotés de la « somme » ou de la « moyenne ». Pour les habitués du SQL « spatial » allergiques à JTS qui possèdent une connexion à un SGBD spatial (PostgreSQL/PostGIS par exemple), les appels aux fonctions spatiales avec passage de paramètres sont envisageables sans à avoir à charger en amont les données dans son SGBD.

# Quelques exemples d’utilisation

• Chargement de fichiers plats en base spatiale pour mise à jour de référentiel géographique sur un serveur de Web Mapping.

• Création d’un fichier Shapefile de polygones à partir d’un fichier Shapefile de polylignes et de points « label » porteurs d’attributs.

• Création de fichiers Shapefile d’entités administratives à partir d’un fichier Shapefile des communes.

# Conclusion

GeoKettle trouve naturellement sa place dès lors qu’un processus régulier d’import ou d’export en masse de fichiers géographiques plats est à réaliser mais autorise aussi (sans atteindre les possibilités et les performances d’un « ModelBuilder » d’ESRI ) la mise en place d’opérations de requetage spatial ou de géotraitements , son avantage principal étant de pouvoir s’affranchir là aussi des différentes sources de données. Par ailleurs et d’un point de vue pratique, l’utilisation de GeoKettle ne perturbe pas les méthodes de travail des utilisateurs de Kettle, les fonctionnalités nouvelles spécifiques étant traduites sous formes de nouvelles étapes (alimentation / extraction), d’autres ayant été intégrées au sein étapes existantes (filtrage, produit cartésien). Malgré toute la souplesse et la richesse intrinsèque offerte par GeoKettle, ce dernier possède encore quelques limites :

• Concernant les extractions / alimentations et même si les fichiers ESRI Shapefile restent couramment utilisés, il manque à l’outil la possibilité de pouvoir lire et écrire dans les formats SIG courants (Mapinfo TAB, GML, KML) etc. L’utilisation de la librairie Geotools devrait permettre d’offrir ces fonctionnalités prochainement. En attendant, il est toujours possible de faire appel au sein de tâches à des outils externes en lignes de commande comme OGR2OGR ou à générer et à transformer certains formats basés sur le XML à partir de briques existantes et de transformations XSL (GML,KML).

• Actuellement, l’utilisation des opérateurs de construction géométrique « Buffer, Union, Intersection, Erase, etc. » à travers les scripts reste réservée aux initiés JTS. Là aussi, la mise à disposition d’étapes et d’interfaces graphiques appropriées est annoncé.

• Il manque encore quelques fonctionnalités comme les agrégations (dissolve) de géométries ou la générations de lignes à partir de multi-géométries (Ceci peut être cependant réalisé à travers JTS)

• Enfin, coté performances, si les imports et exports de données géographiques ne posent pas de problèmes particuliers, la manipulation évoluée (opérations successives d’union de buffer, etc) des géométries à travers des scripts JTS consomme beaucoup de ressources. Il faut garder à l’esprit que GeoKettle reste un outil ETL générique et q’uil n’a pas vocation à remplacer les outils SIG spécifiques.

# L’avis du spécialiste BI d’Atol

GeoKettle est un projet de Business Intelligence Open Source développé par Spatialytics, une société québecoise qui offre des services et des solutions de GeoBI. A noter que cette société développe également deux autres projets très intéressants dans le domaine du GeoBI :

• GeoMondrian, une version “géo-capable” du serveur OLAP Mondrian que l’on retrouve dans sa version de base dans les plates-formes OSBI Pentaho et JasperServer.GeoMondrian permet une intégration consistante d’objets spatiaux (géométries) dans une structure de données en cube plutôt que de devoir les obtenir ailleurs, à partir d’un SGBD spatial, un Service Web ou des fichiers SIG. GeoMondrian intègre également les premières extensions spatiales au langage de requête multidimensionnel MDX ajoutant ainsi de puissantes capacités de requête et d’analyse spatiale dans les cubes.

• SOLAPLayers (ex « Spatialytics ») est un framework cartographique web 2.0 pouvant être intégré dans des tableaux de bord existants afin de permettre la navigation et l’interrogation spatiale (OLAP Spatial ou SOLAP) de cubes de données, comme ceux que supporte GeoMondrian. Il s’appuie sur OpenLayers et Dojo et permet la connexion à un serveur SOLAP tel que GeoMondrian, la navigation dans des cubes avec contenu géospatial, la représentation cartographique de données et mesures statistiques sous forme de cartes thématiques statiques ou dynamiques.