L’utilisation du format GML est aujourd’hui courante dans les fichiers d’échanges XML. Parallèlement, les outils ETL procurent de réels avantages pour mettre en place les chaines de traitements liées à ces besoins d’échanger (changements de format et/ou de structure de la données, échanges entre plateformes, etc.). Aujourd’hui, et à moins de disposer d’un ETL spatial évolué ou de faire appel à des librairies externes comme OGR, il faut bien reconnaitre que la manipulation du GML dans les ETL Open source non spatiaux peut s’avérer fastidieuse, ce format étant par nature assez verbeux (emboitement de nœuds successifs). 

Pour les amateurs de Kettle (Pentaho Data Integration), il existera pourtant prochainement une solution : Exploiter conjointement la librairie JTS et la future brique améliorée de lecture XML disponible dans la prochaine version PDI 4.2 (en cours de développement). Les paragraphes suivants expliquent la démarche à suivre pour réaliser ce genre de traitements.

# Mise en pratique

Pour notre exemple, nous disposons des outils suivants :

Pentaho Data Intégration permet nativement de faire appel à des librairies Java au sein des étapes « Appel script interprété Rhino ». Pour pouvoir exploiter la librairie JTS à travers ces étapes, il faut déposer au préalable les jars « jts-1.11.jar » et « jtsio-1.11.jar » dans le dossier libext de PDI.
 
Principe

Les transformations proposées ci-après correspondent à deux besoins simples :

  • Comment lire un contenu GML pour pouvoir l’intégrer en base de données spatiale ?
  • Comment produire un fichier XML avec du contenu au format GML à partir d’une base de données spatiale ?

# Intégrer un contenu GML en base de données spatiale

Dans cet exemple, nous disposons d’un fichier XML regroupant des îlots agricoles (entité administrative utilisée par les agriculteurs dans le cadre de la Politique Agricole Commune pour prétendre au versement d’aides européennes) et des parcelles culturales (limites d’une même culture = les « champs »).

  • Un îlot peut contenir une ou plusieurs parcelles culturales et possède une géométrie de type « polygone » équivalente à l’union géométrique des parcelles qui le compose,
  • Une parcelle possède une géométrie de type « polygone » et ne peut être rattachée qu’a un seul îlot.

Notre fichier XML de départ possède la structure suivante ; la description géométrique des objets étant assurée par le GML.

Notre base de données relationnelle est constituée de 2 tables, 1 des îlots, 1 des parcelles. Chaque parcelle faisant référence à 1 îlot.

Nous avons simplifié les aspects liés à la géographie en omettant les contraintes sur le SRID ,le type de géométrie et la dimension.

La transformation Kettle est composée des étapes (steps) principales suivantes :

  • la lecture du fichier XML/GML avec récupération des noeud ilot. Pour chaque îlot, on récupère notamment le nœud « geometrie » (GML) et le nœud « parcelles ».

  • Le traitement d’intégration des îlots s’effectue avec les étapes suivantes
    • Conversion des géométries GML en WKT par appel à la librairie JTS.

  • Insertion dans PostGis des îlots via une instruction SQL. Les brique d’insertion « classiques » ne peuvent ici fonctionner car le type « Geometry » n’est reconnu que dans GeoKettle. Malheureusement, GeoKettle ne dispose pas encore des possibilités de récupération des noeuds de PDI 4.2 !!

  • Le traitement des parcelles s’effectue en récupérant et en traitant les informations du noeud « parcelles » de chaque îlot. Les étapes sont similaires à celles utilisées pour l’insertion en base des îlots. On s’assurera néanmoins que les îlots sont bien présents en base avant d’insérer les parcelles pour éviter les erreurs liées au FK (relation îlot / parcelle sur le numéro d’îlot) via une étape « Bloquage lignes lié à d’autres étapes ».

Remarque : Nous passons ici par le processus GML->WKT->St_GeomFromText mais les versions récentes de PostGIS permettent de créer une géométrie directement à partir de GML via la fonction St_GeomFromGml

# Générer un fichier XML/GML à partir de géométries PostGis

Dans cette transformation, nous réalisons l’étape inverse qui consiste à produire un fichier XML contenant des géométries GML à partir de 2 tables spatiales (les tables ilot et parcelle mentionnées dans la transformation précédente).

Les étapes principales sont les suivantes :

  • Extraction des géométries des îlots et des parcelles dans le format WKT via la fonction St_AsText().

  • Conversion des géométries WKT en géométries GML via JTS.

  • Créations de lignes XML et jointures XML permettant de produire la structure XML avec les « emboitements » ilot-parcelles attendus.

  • Génération du fichier XML final à partir de l’étape « Alimentation fichier ». Attention à désactiver la création de l’entête et les aspects liés à la production de TXT/CSV.

Remarques : L’utilisation des jointures XML peut paraître un peu fastidieuse. Il est possible de produire un fichier XML basique et passer ensuite par un job assurant une transformation XSL à partir d’un fichier approprié. PostGIS propose une fonction St_AsGml qui évite de passer par l’étape Script Rhino permettant d’assurer la conversion « WKT-> GML » sans exploitation de JTS.

# Conclusion

Même sans utiliser des ETL spatiaux et dans la mesure ou les traitements du GML et/ou des géométries restent limités au regard des aux autres traitements (l’utilisation de scripts pénalise les temps de traitement), il est tout à fait possible de se tirer d’affaire en utilisant les ETL « Classiques ». Évidement, l’idéal serait de disposer d’une version de Geokettle en adéquation avec les dernières version de PDI (encore un peu de patience !). Plus globalement et au delà des aspects GML, la brique « Extraction de données depuis XML » permettra désormais de récupérer facilement les différentes structures XML utilisées pour la représentation de l’information géographique (KML, GPX, etc). 

Tweetez
Partagez
Partagez
0 Partages