research/vegdud/raster

TracNav

ANR VEGDUD - Image processing (reponsable Erwan Bocher + Nathalie Long)

Objectif général

L'objectif du travail est d'intégrer dans la plateforme OrbisGIS des outils pour représenter et traiter des images satellitaires ainsi que des modèles numériques de terrain de grandes tailles (fichier superieur à 2 G0). Nous utiliserons le terme georaster pour designer les images.

Objectifs

Definition d'un georaster (raster dataset) : ¶

A raster dataset is any valid raster format organized into one or more bands. Each band consists of an array of pixels (cells), and each pixel has a value. A raster dataset has at least one band. More than one raster dataset can be spatially appended (mosaicked) together into a larger, single, continuous raster dataset. source :  http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=Raster_data_organization

Questionnements méthodologiques : ¶

En dehors des problématiques de représentations et d'accès aux images volumineuses, ce travail devra s'intéresser à la question de l'intégration des traitements dans le langage SQL spatial de la plateforme OrbisGIS.

Contraintes techniques : ¶

  • Le développement sera réalisé uniquement en JAVA et sur la base de la librairie GDMS. Il se substituera à la bibliothèque GRAP qui est basée sur ImageJ.
  • Nous utiliserons les IO de BEAM, outil de traitement d'images développé pour l'agence spatiale européenne :  http://www.brockmann-consult.de/cms/web/beam.
  • La librairie JAI (Java Advanced Imaging) sera utilisée pour les traitements :  https://jai.dev.java.net/.
  • Des tests unitaires devront être réalisés.

Contraintes générales : ¶

Pour faciliter les échanges et la compréhension du travail, les outils développées seront résumés sous le nom de projet GRAP-2 : GeoRaster? Analysis and Processing.

Les développements devront être décrits dans une feuille de route sur le TRAC.

Les documents suivants devront être produits :

  • Modélisation UML,
  • Documentation développeur.

Les développements seront déposés sous licence GPL et versés sur le SVN de la plateforme OrbisGIS.

Adresse du svn :  http://geosysin.iict.ch/irstv-svn/branches/orbisgis/imageProcessing

Parcourir le svn :  http://geosysin.iict.ch/irstv-trac/browser/branches/orbisgis/imageProcessing

Applications

La librairie GRAP-2 sera expérimentée dans le cadre des activités du PRF Télédétection Urbaine de l'IRSTV. A ce sujet, une liste des fonctions de traitements à développer est donnée en annexe de cette page.

Plan de travail

Le travail sera réalisé par Alexis Guéganno dans un premier temps sous la forme d'un stage de fin d'étude de diplôme d'ingénieur de l'Ecole Centrale de Nantes puis dans un deuxième temps sous la forme d'un CDD ingénieur de 6 mois. Le stage sera réalisé en Suisse chez notre partenaire scientifique le laboratoire GEOSYSIN de la HEIG-VD. Un état de l'art précédera le stage.

État de l'art

Le démarrage du stage est bien entendu précédé d'une recherche bibliographique permettant de faire le point sur l'existant à différents niveaux. J'ai décidé de scinder mes recherches en trois axes : un sur le traitement d'image, un sur les requêtes SQL appliquées aux SIG et un orienté vers le stockage et le traitement efficace de fichiers volumineux.

Mes recherches se sont appuyées principalement sur les articles accessibles grâce aux abonnements dont dispose l'École Centrale de Nantes. En particulier, j'ai effectué mes recherches dans les ressources des éditeurs Elsevier (www.sciencedirect.com) et Springer (www.springerlink.com). Dans une moindre mesure, j'ai eu recours à l'outil Google Scholar

Traitement d'image

Etant donnée la nature du sujet, il m'a semblé naturel d'évaluer les techniques actuellement utilisées pour traiter les images satellitaires, qui sont en fait des jeux de données raster, afin d'en extraire des informations de façon automatisée et efficace. Les articles que j'ai retenu sont les suivants.

  • Péteri, Celle, Ranchin, Detection and extraction of road networks from high resolution satellite images
  • Sharma, Mioc, Anton, Polygon Feature Extraction from satellite imagery based on colour image segmentation and medial axis. The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXVII, part B3a
  • Mena, Malpica, An automatic method for road extraction in rural and semi urban areas starting from high resolution satellite imagery, Pattern Recognition Letters 26 (2005), 1201-1220
  • Sohn, Dowman Data fusion of satellite imagery and LiDAR data for automatic building extraction, ISPRS Journal of Photogrammetry and Remote Sensing 62 (2007) 43-63
  • Tholey, Digital processing of Earth observation images, Surveys in Geophysics 21 (2000) 209-222
  • Tripathi, N. K., Gokhale, K. V. G. K. and Siddiqui, M. U.(2000) Directional morphological image transforms for lineament extraction from remotely sensed images, International Journal of Remote Sensing, 21: 17, 3281-3292
  • Derivaut, Forestier, Wemmert, Lefévre, Extraction de détecteurs d’objets urbains à partir d’une ontologie
  • Erus, Loménie, Extraction of Cartographic Objects on High Resolution Satellite Images for Object Model Generation, hal-00136179, version 1 - 12 Mar 2007
  • G. Guzmán, S. Levachkine, M. Torres, R. Quintero, and M. Moreno, Extraction and Specialization of Geo-spatial Objects in Geo-images Using Semantic Compression Algorithm
  • H. Liu, J. Li and M. A. Chapman, Automated Road Extraction from Satellite Imagery Using Hybrid Genetic Algorithms and Cluster Analysis, Journal of Environmental Informatics 1 (2) 40-47 (2003)
  • Pohl, Van Genderen, M ultisensor image fusion in remote sensing: concepts, methods and applications, Internation Journal of Remote Sensing, 1998 , vol. 19 , no. 5 , 823± 854
  • K. Waldemark , T. Lindblad, V. Becanovi, J. L.L. Guillen , P. L. Klingner, Patterns from the sky Satellite image analysis using pulse coupled neural networks for pre-processing, segmentation and edge detection, Pattern Recognition Letters 21 (2000) 227±237
  • Soh, Tsatsoulis ,Segmentation of Satellite Imagery of Natural Scenes Using Data Mining, IEEE TRANSACTIONS ON GEOSCIENCE AND REMOTE SENSING, VOL. 37, NO. 2, MARCH 1999
  • Malpica, Splines Interpolation in High Resolution Satellite Imagery
  • Miguel Torres, G. Guzman, Rolando Quintero, Marco Moreno, and Serguei Levachkine, Semantic Supervised Clustering to Land Classification in Geo-Images, KES 2005, LNAI 3683, pp. 248–254, 2005.
  • Norman Fomferra, Carsten Brockmann, Beam - the ENVISAT MERIS and AATSR Toolbox

Moteur de requêtes

Le moteur de requêtes des SIG consitue un point essentiel de leur fonctionnement. Il est en effet le coeur du mécanisme d'aide à la décision que représente le logiciel. Il s'agit donc d'un des points d'étude de ma bibliographie. Je me suis logiquement dirigé vers les articles traitant directement de GDMS, la couche d'abstraction utilisée par OrbisGIS, produits par l'IRSTV. J'ai également cherché d'autres sources, afin de confronter (si possible) les méthodes, et surtout de dégager des méthodes propres de gestion des documents de type raster. Les articles retenus sont les suivants :

  • Leonardo Guerreiro Azevedo, Geraldo Zimbrão1, Jano Moreira de Souza : Approximate Query Processing in Spatial Databases Using Raster Signatures
  • Piotr Bajerski, Stanisław Kozielski : Computational Model for Efficient Processing of Geofield Queries
  • Stephan Nebiker and Lukas Relly, Concepts and System Architectures for the Management of Very Large Spatial Raster Objects in a Database Framework
  • Hanan Samet, Database and Representation Issues in Geographic Information Systems (GIS)
  • Erwan Bocher, Thomas Leduc, Guillaume Moreau, Fernando González Cortés, GDMS: An abstraction layer to enhance Spatial Data Infrastructures usability, hal-00329500, version 1 - 11 Oct 2008
  • Thomas Leduc, Erwan Bocher, Fernando González Cortés, Guillaume Moreau, GDMS-R: A mixed SQL to manage raster and vector data, GIS 2009, Ostrava : Tchèque, République (2009)
  • Alain Buogo, Jean-Jacques Chevallier : Spatial Information Systems And Information Integration, Comput., Environ. and Urban Systems, Vol. 19, No. 3, pp. 161-170, 1995
  • Max J. Egenhofer, Spatial SQL: A Query and Presentation Language
  • Erwan Bocher, Thomas Leduc, Nathalie Long, Fernando Gonzales­ Cortes, Guillaume Moreau : urbSAT: from spatial SQL to urban indicators , Free and Open Source Software for Geospatial Conference - FOSS4G'2008, Cape Town : South Africa (2008)
  • João Pedro Cerveira Cordeiro, Gilberto Câmara, Ubirajara Moura de Freitas, Felipe Almeida, Yet Another Map Algebra, Geoinformatica (2009) 13:183–202
  • Gilberto Câmara, Danilo Palomo, Ricardo Cartaxo Modesto de Souza, Olga Regina Fradico de Oliveira, Towards a generalized map algebra: principles and data types,

Représentation et stockage

  • Asheer Bachoo, Frans van den Bergh, Albert Gazendam, A comparison of data file and storage configurations for efficient temporal access of satellite image data, Proceedings of the academic track of the 2008 FOSS4G Conference, incorporating the GISSA 2008 Conference
  • Sachin More and Alok Choudhary, Storage Optimization for Large Multidimensional Datasets, Center for Parallel and Distributed Computing, November 4, 1999, Technical Report No. CPDC-TR-9911-018
  • Maude Manouvrier, Marta Rukoz, Genevieve Jomier, Quadtree representations for storage and manipulation of clusters of images, Image and Vision Computing 00 (2002) 000±000
  • Jay Smith, Vladimir Shestak, Howard Jay Siegel, Suzy Price, Larry Teklits, Prasanna Sugavanam , Robust resource allocation in a cluster based imaging system, Parallel Computing 35 (2009) 389–400

Plan de travail du stage

  • Étude de la Java Distribution License et de la java Research License qui protègent JAI
  • Étude des mécanismes de tuilage en cache proposés par JAI
  • Étude des mécanismes de mise en cache utilisés par BEAM
  • Étude de la spécification WMS et de la RFC WMTS - Recherches sur WMS-C - Confrontation des divers documents
  • Évaluation des possibilités de portage de la librairie GDAL
  • Écriture de spécifications UML avant écriture des codes pour OrbisGIS
  • Écriture des codes, avec documentation et tests

Plan de travail du CDD

Compte rendus de réunion

Compte rendu de la réunion du 28 Mars - Réunion de préparation du stage

Étaient présents à la réunion Alexis Guéganno et Erwan Bocher. La réunion a pour objectif de cerner précisément les objectifs du stage, et d'ébaucher une méthode de travail qui sera appliquée pour le stage.

L'objectif du stage est le suivant. Je devrai travailler à l'intégration dans la plate forme OrbisGIS d'une librairie pour traiter des images satellitaire et des MNT. Ces traitements seront utilisés pour étudier l'évolution de la tâche urbaine.

Les algorithmes chargés de l'étude de l'évolution de la tâche urbaine sont déjà disponibles. C'est la taille des fichiers de données qui sont problématiques. Le logiciel doit être capable de traiter des images de plusieur Giga-octets, et d'intégrer parfaitement le résultat de ces traitements au langage d'OrbisGIS. Le résultat consistera en un framework devant permettre aux chercheurs de l'IRSTV, mais également aux contributeurs d'OrbisGIS, de développer en partant d'une base efficace. La partie utilisateur sera donc également à prendre en compte.

Plusieurs questions se posent à propos :

  • Des méthodes d'accès aux données
  • Du traitement de la donnée
  • De la représentation de la donnée
  • De l'ordre de ces différentes phases. On peut représenter puis traiter, et vice versa.
  • De la granularité des jeux de données mis en oeuvre lors de l'étude de l'évolution de la tâche urbaine. La résolution ne sera pas constante, et pourra varier de 10m à 50cm.

Une proposition de normalisation de l'objet Raster a déjà été proposée lors des travaux sur wktraster (wkt signifiant Well Known Text). Cette méthode permet une représentation du raster dans une base de données, en prenant en compte, par exemple, les bandes de données, la résolution de l'image... L'adresse de l'image peut pointer vers l'extérieur de la base de données, ou l'objet peut être inséré directement sous forme de Binary Large Object (BLOB) . Ce choix contraint déjà la façon d'accéder à la donnée, les méthodes mises en oeuvre différant dans les deux cas, l'intégration dans OrbisGIS et GDMS différant elle aussi.

Le choix de la technique de représentation se confronte aux différentes méthodes de tuilage déjà existantes. A priori, nous utiliserons un objet raster original, ne dépendant pas de la norme Grid Coverage. Nous étudierons peut être a posteriori les possibilités de compatibilité avec cette norme de description des images.

La problématique du choix de la librairie pour le traitement d'images se heurte aux forces et faiblesses des différentes bibliothèques déjà écrites et libres.  Java Advanced Imaging est a priori ce qui se fait de plus puissant en Java. Cette librairie se heurte cependant à de nombreuses limitations, notamment sur le choix de la sortie des filtres utilisés en traitement d'image. La librairie est puissante, mettant en avant la notion de "noeud de traitement", mais est difficile d'accès pour les nouveaux venus. Développée par Oracle, depuis que cette entreprise à racheter Sun Microsystems, cette librairie est protégée par une licence assez ambigue, qu'Oracle ne cherche pas vraiment à clarifier. Il faudra donc identifier clairement la licence protégeant les codes de JAI.

Une autre librairie, GDAL, présenterait moins de problèmes a priori. Également puissante, elle permet des traitements rapides et souples, et ne pose a priori pas de problèmes de licences. Le problème provient du fait qu'elle est écrite en C, pas en Java. Un portage serait donc nécessaire. un tel choix devra prendre en compte les différences intrinsèques des langages Java et C, notamment sur les façons d'accéder directement à la mémoire et d'y effectuer directement des opérations arithmétiques.

Réunion de lancement du stage - 1 Mai 2010

Suite à mon arrivée dans l'École, j'ai été présenté rapidement à l'ensemble de l'équipe du laboratoire. Nous avons ensuite tenu une réunion de lancement avec Olivier Ertz, Maître de Stage sur place. Nous avons abordé plusieurs points relatifs au stage, afin que je puisse commencer le plus rapidement et le plus efficacement possible. Plusieurs points ont été soulevés.

Rappelons en premier lieu que le travail prévu va être effectué en deux parties. La première sera effectuée pendant le stage, la seconde dans le cadre d'un CDD. Par conséquent, le travail abordé dans le cadre du stage ne sera que partiel par rapport à l'ensemble des tâches à mener dans le projet. Il va donc falloir définir précisément les tâches qui seront abordées dans le cadre du stage.

Étant données les problématiques déjà identifiées, plusieurs points ont été mis en avant. La problématique de tuilage apparaît être le premier point à étudier. Plusieurs normes de mise en cache existent déjà. On notera en particulier la norme WMTS proposée par l'Open Geographic Consortium. D'autres existent : WMS-C, TMS... Ces normes devront donc être confrontées, et si une norme est choisie, elle devra servir de base aux spécifications.

Notons que les normes en question correspondent à la structure à obtenir en fin de traitement. Les mécanismes sous-jacent ne sont pas imposés par les spécifications. Il est donc envisageable de réaliser les choses de façon indépendante.

La mise en cache peut être problématiques dans le cadre d'une utilisation Desktop de la librairie de tuilage. En effet, le stockage permanent des éléments de cache impose à l'utilisateur de disposer de l'espace disque nécessaire. Par ailleurs, une utilisation dans le cadre de communications client-serveur impose a priori une mise en cache permanente, afin d'optimiser la rapidité d'accès aux données.

La comparaison des normes de mise en cache devrait donner lieu à la production d'un document pouvant servir de support de cours. L'étude de ces normes devra donc être accompagnée d'un phase de prototypage, afin de pouvoir mettre en avant les différences entre les normes pendant l'utilisation.

La structure de Beam devra être étudiée, notamment pour analyser les mécanismes de mise en cache de ce ce logiciel. Encore une fois, la pertinence de cette étude sera contrainte au choix de JAI comme librairie de base pour les traitements d'image. Afin d'évaluer cette pertinence, la librGDAL devra également être étudiée.

Enfin, il sera intéressant d'envisager l'utilisation des codes dédiés au pyramidage sur des couches Vector. Il faudra donc adapté les possibilités d'adpatation du résultat obtenu pour le raster pour les couches vector.

Évaluation technologique

Objectifs

Le présent document est le résultat du travail introductif du projet d'étude que je mène au sein de la Haute École d'Ingénierie et de Gestion du canton de Vaud (HEIG-VD), en partenariat avec l'Institut de Recherche des Sciences et Technologies de la Ville (IRSTV). Ce travail préparatoire doit mettre en avant la technologie de traitement d'image la plus adaptée pour l'écriture d'une bibliothèque à intégrer au sein de GDMS, logiciel développé à l'IRSTV. La bibliothèque devra être capable de traiter des données de taille importante, de plusieurs Giga-octets.

Le développement sera réalisé en Java, et devra donc s'appuyer sur une technologie adaptée. Plusieurs technologies sont en concurrence

  • La bibliothèque Java Advanced Imaging.
  • Une bibliothèque de traitement d'image libre existe également.
  • Enfin, un portage de la bibliothèque GDAL, écrite en C/C++, est envisageable.

L'évaluation des outils disponibles devra prendre en compte la faisabilité technique et la charge de travail conséquente. Par ailleurs, il faudra également s'assurer de la compatibilité des diverses licences qui seront mises en jeu par ces acteurs extérieurs. GDMS, et plus généralement OrbisGIS sont protégés par la General Public License. Nous devons nous assurer de ne pas violer les règles protégeant les codes de ces logiciels.

Les fonctions de la librairie seront a priori les suivantes :

  • Gestion des entrées sorties pour les images raster.
  • Implémentation de mécanismes de tuilage et de mise en cache.
  • Mise en place d'une interface permettant aux utilisateurs avancés d'écrire des algorithmes de traitement d'images de façon simplifiée.
  • Communication et intégration dans GDMS.

Évaluation des solutions

Utilisation de Java Advanced Imaging (JAI)

Présentation

La bibliothèque Java Advanced Imaging est une API développée conjointement par Oracle, récent acquisiteur de Sun Microsystems, et la communauté Java.net. La bibliothèque est développée à un niveau très proche de la machine virtuelle Java. Il s'agit notamment de la solution retenue et utilisée par Brockmann Consult pour les mécanismes de mise en cache utilisés dans BEAM, logiciel permettant la visualisation de gros volumes de données.

Possibilités techniques

L'interface de programmation est fournie avec énormément de mécanismes de traitement d'images, et peut les manipuler en tant que fichiers (pour les entrées-sorties) et en tant qu'images (au sens mathématique). Elle apporte donc tous les mécanismes de manipulation des fichiers pour de nombreux formats, ainsi que des opérateurs de traitements d'images classiques.

La constitution des chaînes de traitement est puissante, mais déroutante et parfois contre-intuitive. La mise en place d'une API de développement pour les développeurs externes devra donc réaliser l'interface entre ces mécanismes et les codes développés par ces contributeurs.

Des mécanismes de tuilage sont directement intégrés dans JAI. De plus, des interfaces (au sens de Java) pour la mise en cache des tuiles sont présentes, et permettent donc d'avoir une première idée de la structure à donner au cache. Ces interfaces laissent cependant assez de libertés aux développeurs pour qu'ils puissent spécifier la forme de leur cache eux-mêmes, notamment en vue de respecter des standards d'échanges de tuiles (WMTS ou WMS-C, par exemple).

JAI a également quelques faiblesses. On retiendra en particulier les difficultés qu'a JAI avec certains fichiers TIFF. Le format TIFF est très courant pour les utilisateurs de SIG, et JAI n'est pas capable de manipuler les TIFF contenant des images planaires. Il est cependant possible de pallier ce problème en ayant recours à des mécanismes sous-jacents de JAI et de imageio, l'interface standard de manipulation des images de la machine virtuelle Java. C'est en particulier la solution qui a été retenue par BEAM. Contrairement à l'ensemble des codes évalués ici, ces classes ne faisant pas partie de l'API publique de Java, elles ne sont absolument pas documentées. Les sources sont cependant disponibles en ligne.

Licence

Parmi les trois solutions proposées, JAI est celle dont la licence peut a priori être la plus problématique. En effet, les codes de l'API sont protégés par deux licences, selon la situation. Dans le cas où les codes sont modifiés dans des buts de recherche, la licence qui s'applique est la Java Research Licence (JRL). Dans le cas où les codes modifiés sont dédiés à un plus large public, et où leur diffusion apporte aux développeurs un avantage concurrentiel (des contrats ou des financements, par exemple), la licence qui a cours est la Java Development License (JDL). C'est donc la JDL qui s'applique dans notre cas.

La modification de l'API selon les termes de la JDL impose plusieurs conditions :

  • La librairie modifiée doit répondre au Test Compatibility Kit (TCK), batterie de test développée par Sun, et les développeurs doivent prouver cette compatibilité à Oracle par leur propres moyens. Le TCK n'est pas ouvert.
  • La JDL constitue un accord signé entre deux parties, Oracle et les développeurs. Cet accord doit être régulièrement renouvelé, ainsi que les tests l'accompagnant.
  • Potentiellement, la JDL peut être accompagnée d'une redevance à payer à Oracle, bien que ce ne soit pas le cas actuellement.

Cependant, cette licence ne s'applique que dans le cas ou la librairie est modifiée par l'équipe de développement de GDMS. Dans notre cas, il serait plutôt envisagé de recourir à JAI comme librairie externe, ce qui est tout à fait autorisé par la GPL.

Par ailleurs, même dans le cas où nous modifierions JAI, la librairie résultante serait elle aussi indépendante. Il resterait donc possible de l'utiliser comme librairie externe, plutôt que d'inclure directement les codes modifiés dans GDMS. De cette façon, nous resterions là aussi en accord avec les termes de la GPL.

Développements basés sur ImageJ

Présentation

ImageJ est un ensemble de librairies et de plugins écrits en Java, dédiés au traitement d'image. Il s'agit d'un projet libre, soutenu par une communauté indépendante et active.

Possibilités techniques

ImageJ propose un support pour un grand nombre de formats, que ce soit le JPG, le PGM, le PNG... Le support pour les TIFF est a priori limité, puisque seuls les TIFF non-compressés sont lus par la version basique d'ImageJ. La librairie s'accompagne d'un grand nombre d'opérateurs de traitements d'images.

Les performances de traitement et d'affichage sont a priori excellentes. Le site officiel prétend pouvoir traiter une image de 2048*2048 pixels en un dixième de seconde... sans préciser le format de l'image traitée. ImageJ a recours à une mise en mémoire complète de l'image à traiter, ce qui explique les performances affichées ici. Dans notre cas (images de plusieurs Go), une mise en mémoire brute ne peut être envisagée. Même en supposant que la mémoire soit physiquement disponible sans mise en swap, rien ne garantit que la JVM soit capable de la traiter correctement.

Un plugin de mise en cache pour ImageJ existe. Il devrait être complété par des méthodes de tuilage adaptées à nos données d'une part, et enrichi d'autres part pour répondre à nos besoins de mise en cache à la volée ou en dur.

L'utilisation d'ImageJ imposerait donc une réécriture de la gestion de la mémoire, avec ajout de mécanismes de tuilage et de mise en cache. Certains algorithmes de traitement d'ImageJ devraient peut être être modifiés en conséquence.

Enfin, notons que ImageJ recours assez souvent à des classes externes lors de ces traitements, classes provenant généralement de JAI...

Licence

ImageJ est publié sous licence GPLv2, donc compatible avec GDMS.

Portage de GDAL

Présentation

GDAL est une bibliothèque développée en C/C++ dédiée au traitement d'image. Elle est particulièrement dédiée au traitement d'images raster. Il s'agit de la librairie qui était utilisée par WorldWind?, logiciel développé par la NASA, avant que l'agence spatiale ne décide de se tourner vers Java.

Possibilités techniques

GDAL répond a priori à l'ensemble des besoins de base de notre projet. La librairie gère tous les principaux formats raster, et supporte en particulier toutes les formes de TIFF et de GeoTIFF. La librairie propose des mécanismes de tuilage et de mise en cache performants, ainsi que de nombreux algorithmes de traitement d'image. Mais elle est écrite en C/C++.

Utiliser une solution basée sur GDAL impose donc une réécriture complète en Java. Cette solution s'appuierait donc certainement sur les mécanismes de base d'ImageJ ou de JAI, ou au moins d'imageio. De plus, une relecture complète des codes de GDAL serait nécessaire. La librairie étant multi-plateforme et écrite en C/C++, elle contient de très nombreuses directives de précompilations qui alourdissent considérablement le code, et ajoutent de la complexité à des algorithmes déjà très puissants.

Dans le cas d'un portage, donc, nous pourrions nous appuyer sur des codes existant. Cependant, nous devrions assurer une réécriture complète, adaptée au langage Java, d'une très grande quantité de codes, en respectant les mêmes contraintes que sur un développement original. De plus, les mécanismes mis en oeuvre en C/C++ sont a priori différents de ceux envisageables en Java. Les différences entre les deux langages, et surtout le recours à une machine virtuelle intermédiaire pour les logiciels écrits en Java, remettent en cause les choix fait pour un logiciels écrit en C/C++.

Licence

GDAL est publié sous licence MIT/X11, compatible avec la GPLv3.

Recommandation pour le choix.

Étant donnés les divers arguments présentés ici, une solution basée sur JAI est recommandée. En effet, les chaînes de traitement sont riches et performantes, et les possibilités de tuilage existent déjà. De plus, les mécanismes de mise en cache sont préparés par l'API, et un exemple de mise en oeuvre est présent dans BEAM (qui est protégé par la GPL).

La solution sera cependant mixte, dans le sens où une partie des chargement et écritures des images seront réalisés directement par imageio, ou par ses mécanismes sous-jacents, plutôt que par l'API JAI elle-même, afin de pallier aux quelques faiblesses de celle-ci.

Liens

Notes diverses sur GDMS et WKTRaster

Implémentation de WKTRaster

L'implémentation est en cours. Plusieurs choses sont à noter...

Une nouvelle Value fait son entrée dans GDMS (WKTRasterValue), destinée à obtenir une représentation de l'objet WKTRaster, assez proche de l'objet décrit par la communauté PostGIS. L'objet stocké dans GDMS sera certainement différent, et sera adapté aux besoins d'OrbisGIS. La présence de certains attributs devra être discutée.

La mise en base "brute" des objets raster dans la base, au format binaire, sera certainement abandonnée. L'implémentation d'une telle fonctionnalité, si elle est faite, ne sera réalisée que plus tard. Cette mise en base, pour les fichiers de grande taille, serait tout à fait problématique. Si cette utilisation de type BLOB est intronisée, il faudra mettre en place un mécanisme de choix pour l'utilisateur.

Le pilote pour les raster (AbstractRasterDriver?) va disparaître, à terme. Il va être remplacé par un WKTRasterDriver, qui sera étendu pour supporter les formats de fichier désirés. Les opérations de base (ouverture et fermeture, notamment) doivent pouvoir y être faite directement. Surtout pour les Geotiff (dans la mesure où toutes les informations sont contenues dans le même fichier).

Pour les formats de fichier différents du GeoTIFF, il faudra récupérer les données géographiques dans un fichier WorldFile? (TWF) présent à côté du raster désiré. L'import des données depuis ce format de fichier ne sera sans doute pas problématique, celui-ci étant extrêmement simple.

En plus de la nouvelle Value, il faudra peut être ajouter un Type pour avoir une mise en base efficace.

une fois la mise en base achevée, il faudra mettre en place un protocole de jonction avec le moteur de rendu. Il va falloir gérer les problématiques de positionnement et de taille d'affichage pour les tuiles, ainsi que la sélection intelligente des tuiles pour le rendu. Dans la mesure où l'on peut connaître aisément la position et les dimensions réelles d'une tuile, le positionnement ne devrait pas poser de difficultés insurmontables.

On doit pouvoir faire un certain nombre d'opérations (SQL) sans charger de produit en mémoire, en ne s'appuyant que sur l'"objet WKTRaster". Par exemple, on n'a absolument pas besoin de charger un bout d'une image pour déterminer si elle intersecte une géométrie. À partir du moment où on a les dimensions et la positions des tuiles, on peut en retirer un rectangle et calculer s'il y a intersection. Si on veut le contenu de l'intersection côté géométrie, de même. Si on veut le contenu de l'intersection côté raster, l'accès au Product sera par contre indispensable. Les opérateurs pouvant opérer sur les raster **devront** prendre cela en compte.

À propos des attributs proposés dans le WKTRaster de PostGIS

La spécification WKTRaster proposée par la communauté PostGIS est un exemple de mise en base de données par référence pour des objets de types raster. L'objectif est de conserver des bases de données de taille raisonnable, et donc de préserver leur efficacité, en n'inscrivant pas dans les fichiers de la base.

Notre objectif est d'implémenter une technologie reposant sur le même concept (à savoir l'utilisation de références pour stocker les raster en base de données), adaptée à GDMS et OrbisGIS. Les colonnes proposées dans la table PostGIS sont les suivantes :

r_column character varying(256) Nom de la colonne
srid integer Permet d'identifier le CRS.
pixel_types array[varchar] Tableau d'entier, permettant de connaitre le type de pixel pour chacune des bandes
out_db array[boolean] Précise si le fichier est stocké comme un BLOB ou si une référence est utilisée
regular_blocking boolean Précise si le découpage des tuiles est régulier
nodata_values array[double] La valeur des pixels NODATA pour chacune des bandes
pixelsize_x double La taille des pixels en abscisse
pixelsize_y double La taille des pixels en ordonnée
blocksize_x integer Dans le cas d'un découpage régulier, taille d'un bloc selon X
blocksize_y integer Dans le cas d'un découpage régulier, taille d'un bloc selon Y
extent geometry Géométrie contenant le raster

Plusieurs des entrées présentées ici peuvent être discutées :

r_column inchangé
srid Devra être adapté à la représentation des CRS utilisée dans OrbisGIS
pixel_types A priori inutile dans notre cas. À voir la nécessité de cette information (dans la base) pour les traitements...
out_db Tous les rasters devraient être laissés hors de la base, a priori. Le champ devient donc inutile.
regular_blockingLes tables doivent a priori pouvoir contenir des tuiles de dimensions différentes (dans un soucis de généricité). L'option disparaît
nodata_values À étudier, pour les mêmes raisons que pixel_types
pixelsize_x inchangé
pixelsize_y inchangé
blocksize_x Disparait, cf regular_blocking
blocksize_y Disparait, cf regular_blocking
extent Disparait. Peut être retrouvé par l'intermédiaire de l'objet WKTRaster

La forme de l'objet WKTRaster a été très largement modifiée pour la mise en base dans GDMS. En effet, les informations présentées au-dessus, bien qu'inddispensables pour la réalisation des traitements, ne sont pas nécessairement utiles pour l'utilisateur cherchant à visualiser les données, et à réaliser les traitements en question. Nous avons donc choisi d'utiliser une représentation plus compacte de l'objet raster dans la base de données. En effet, les objectifs d'OrbisGIS et de PostGIS sont assez différents. Nos problématiquese de représentation en base de données sont accompagnées de contraintes sur l'affichage des données, et sur la cohérence des informations placées dans la base.

Un objet raster, dans GDMS, abrite un ensemble de tuiles cohérent. Dans la grande majorité des cas, cela signifie que toutes les tuiles d'un objet raster proviennent du même fichier source. Plus généralement, les tuiles sous-jacentes d'un objet WKTRaster devront toutes partager un certain nombres de cractéristiques communes. On peut penser notamment au type d'image, au nombre de bandes, au CRS...

Cette représentation compacte n'empêche pas la remontée des informations relattives à l'image vers l'utilisateur. Bien que non-apparentes, elles seront toujours accessibles via des requêtes SQL.

Avancement des travaux

L'avancement peut être suivi directement depuis une branche du dépôt svn. Pour accéder aux sources directement :

svn co  http://geosysin.iict.ch/irstv-svn/branches/libs/grap2/orbeamgis

Pour consulter les sources en ligne :

 http://geosysin.iict.ch/irstv-trac/browser/branches/libs/grap2/orbeamgis

État des codes

Actuellement, la version placée dans la branche est capable de réaliser l'import des objets raster en base de données, et d'afficher les rasters dans OrbisGIS.

Du point de vue de l'utilisation mémoire, par rapport aux codes actuels, la différence est assez encourageante. En utilisant l'implémentation actuelle de la branche svn sur un raster géoréférencé de 217Mo, et en comparant avec la version du trunk, on obtient les résultats suivants : - Sur la branche de développement, passage de 30 Mo à froid à un maximum de 110Mo suite au chargement. L'utilisation mémoire redescend à 70 Mo (pour une raison à étudier...) - Sur le tronc, l'utilisation mémoire à froid est de 90 Mo. Une fois l'image chargée (sous forme de table, sans affichage), l'utilisation mémoire passe à environ 450Mo, et reste stable.

La différence d'utilisation mémoire pour le chargement est donc d'environ 280Mo (sur un seul import). Les tests seront bien sur à approfondir, pour deux raisons. Les données relevées ici ont été transmises directement par le logiciel, au travers de la vue dédiée à la représentation de l'utilisation mémoire. Ensuite, nous ne parlons ici que de la mise en base de données, et pas de l'affichage. Il est possible qu'une fois l'image chargée dans la version actuelle du logiciel, l'affichage soit plus rapide que celui possible par le biais de BEAM. Les données sont en effet déjà toutes en mémoire, ce qui est plutôt un avantage pour la réactivité des traitements.

En réalisant plusieurs imports, la différence est encore plus frappante. Actuellement, nous nous contentons d'importer quelques références vers des objets sur disque. La majorité de la mémoire utilisée est dédiée aux quelques opérations de lecture nécessaires à l'obtention des méta-données liées à l'image. Une fois les informations mises en base, elles semblent accessibles par le garbage collector (à vérifier, cependant). Dans tous les cas, l'import d'un deuxième raster dans GDMS ne provoque pas nécessairement une augmentation significative de l'empreinte mémoire de la base de données.

Le cache de tuiles par défaut de JAI est actuellement uttilisé. Il s'agit d'un cache non persistant. Il permet d'afficher en quelques secondes les tuiles déjà présentées... pourvu qu'elles n'aient pas été supprimées du cache.

Problématiques soulevées

Des problématiques sont bien entendues soulevées par l'intégration de WKTRaster dans GDMS.

Actuellement, nous travaillons uniquement sur des fichiers sur disque. Lors de l'import en base de données, les éléments WKTRaster sont liés à un produit et à un fichier sur le disque. Les opérations sur les rasters ne sont pour l'instant pas liées à cet objet (elles ont même été temporairement retirées des opérations possibles dans OrbisGIS dans la branche de développement). Quand ces opérations seront de nouveau possibles, il faudra prendre en compte la mise en base des résultats. L'implémentation actuelle impose d'écrire tous les rasters résultants de ces opérations sur le disque avant de réaliser l'import. Une telle limitation pourrait être problématique, notamment si la purge des fichiers temporaires n'est pas efficace.

La remontée des ColorModel? est problématique, dans le cadre des fichiers multi-bande. À chaque bande est associé un modèle de couleur, dans le modèle de onnées de BEAM. Ils peuvent donc être différents, a priori. Cette problématique est encore plus vraie, pour les rasters contenant plus de trois bandes, pour le choix entre l'application d'un modèle de couleur avec plusieurs bandes comme source et l'affichage d'une seule couche. Enfin, rien ne garantit, a priori, que tous les rasters dans une table aient le même nombre de bandes. Le choix du ColorModel? pour l'affichage doit donc, a priori, être fait indépendamment pour chaque raster...

Liens

 http://trac.osgeo.org/postgis/wiki/WKTRaster

 http://trac.osgeo.org/postgis/wiki/WKTRaster/Documentation01

 http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWorking01