Le coin de l'open-source géospatial

Even Rouault : développeur de GDAL-OGR

1. Peux tu faire une présentation de ton parcours professionnel et ce qui t’a amené à travailler dans la géomatique open source ?

Je ne travaille pas, à proprement parler, dans la géomatique Open Source. Je suis actuellement employé par une grande entreprise française dans le secteur de la défense où nous développons des systèmes d’information opérationnels.

La composante cartographique est bien sûr un élément important de tels logiciels et depuis quelques années nous nous appuyons sur divers librairies et programmes Open Source, parmi lesquels GDAL/OGR, Proj.4, libtiff, libgeotiff, OGDI, GEOS, MapServer etc… Au terme d’évaluations, ces solutions nous sont apparues comme celles satisfaisant au mieux nos besoins et contraintes. Parmi les avantages majeurs, il y a l’indépendance par rapport à un fournisseur commercial, l’adaptabilité à des besoins spécifiques (support d’architectures matérielles « exotiques »), la possibilité de pouvoir être autonome et réactif s’il faut corriger d’urgence un bug critique, la capacité à auditer le code du point de vue de sa sécurité, et bien sûr le coût de redistribution nul, ce qui n’est pas négligeable dans le cas de diffusion en série… Au fur et à mesure de l’utilisation de ces logiciels, j’ai été amené à corriger divers bugs et à reporter les corrections et améliorations aux projets en amont.

Mon intérêt pour la géomatique ne date cependant pas de mon entrée dans la vie professionnelle, puisque j’ai fait mes premiers pas dans la programmation quand j’étais ado, à l’époque où mon père me mettait au défi de réaliser des moulinettes de conversion entre formats de données cartographiques pour pouvoir les exploiter et passer d’un outil à un autre.

2. Sur quel(s) projet(s) travailles tu et quel est ton implication dans ce projet ?

Le projet auquel je contribue principalement est GDAL/OGR, depuis 2007. Au début comme contributeur occasionnel de « patchs » dans le cadre de mon activité professionnelle, puis progressivement de manière plus régulière à titre personnel sur mon temps libre. Je me suis intéressé à différents aspects du logiciel :

ajout de nouveaux drivers (ADRG, RPFTOC, Rasterlite, GPX, GeoRSS, BNA, XPLANE) et outils (gdalbuildvrt),

fiabilisation du fonctionnement face à des données corrompues,

extension de la suite de tests de non régression. Celle-ci comporte pas moins de 1500 tests représentant 51 000 lignes de scripts Python pour 639 000 lignes de code C/C++ de la bibliothèque et de ses outils,

remise à jour du binding Java pour GDAL 1.7.0 (http://gdal.org/java pour l’API),

réponses aux questions des utilisateurs sur la liste de discussion (http://lists.osgeo.org/mailman/listinfo/gdal-dev/), etc..

Depuis janvier 2008, j’ai rejoint le Comité de Pilotage du Projet (PSC), qui est une institution obligatoire pour les projets soutenus officiellement par l’OSGeo. Il s’y décide notamment l’attribution des droits en écriture au dépôt Subversion du projet pour les nouveaux contributeurs, les dépenses financées sur le budget du projet (les rentrées d’argent résultent des fonds collectés auprès de divers sponsors) comme le choix d’un mainteneur payé, ou plus généralement tout vote relatif aux décisions importantes du projet.

3. GDAL-OGR n’est-il pas arrivé à une certaine maturation qui ne demande que très peu de développement ou y a t-il de nombreuses pistes de développements ? Comment se présente le futur de GDAL-OGR ?

GDAL/OGR fête cette année ses 10 ans d’existence et est incontestablement arrivé à un haut degré de maturité, tant en fonctionnalités qu’en stabilité. Toutefois, on n’a jamais vraiment fini de corriger les bugs, améliorer les performances, la robustesse, l’intégration avec les nouvelles versions des dépendances externes du projet (un dénombrement rapide en recense au moins 30 !), et évidemment la prise en charge de nouveaux formats, facilitée par l’architecture interne à base de greffons.

Les évolutions se font par touches successives, avec beaucoup de précaution pour éviter les  incompatibilités en termes d’interface de programmation ou les régressions fonctionnelles qui risqueraient de déstabiliser les nombreux logiciels s’appuyant sur le projet.

Concernant le futur de GDAL/OGR, il n’y a pas vraiment de « plan » tracé, ou sinon on m’en a caché l’existence 😉 Je pense que c’est le cas de beaucoup des logiciels Open Source matures dont le développement n’est pas porté majoritairement par une entité commerciale. On ne s’inscrit pas dans une logique de conquête de parts de marché : les nouvelles  fonctions arrivent au fur et à mesure des besoins de chaque contributeur, et très fréquemment à la suite des évolutions dûment financées qui leur sont commandées.

Parmi les développements futurs envisagés, Frank Warmerdam, fondateur du projet, souhaiterait que des progrès soient faits pour améliorer la prise en charge de l’encodage des noms de fichiers ou des données attributaires pour OGR (en particulier l’encodage des attributs de fichiers Shapefile). Une nouvelle API permettant le chargement progressif de données raster (application particulièrement au protocole JPIP) a été proposée et pourrait être intégrée dans une version future du logiciel. (voir http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support).

Quant aux améliorations déjà acquises pour la prochaine version 1.7.0, on peut déjà citer :

la gestion de 5 nouveaux formats raster. En particulier, WKTRaster qui est une extension de PostGIS en cours de développement pour gérer des rasters dans une base de données PostgreSQL. Et Rasterlite, solution très semblable avec stockage dans une base SQLite.

la gestion de 2 nouveaux formats vectoriels : GeoRSS et GPS TrackMaker,

l’utilitaire gdaldem pour effectuer des traitements sur des modèles numériques de terrain

des améliorations/corrections significatives dans la gestion des formats GeoRaster, GeoTIFF, HFA, JPEG2000 (Jasper, Kakadu), NITF, CSV, KML, SQLite (en particulier SpatiaLite), VRT, …

4. Ne manque t-il pas une interface graphique qui permettrait une plus large adoption de cet outil ? Cela n’implique t’il pas une prise en compte de cette problématique au sein du projet ?

Je ne pense pas qu’on puisse dire que GDAL/OGR souffre d’une faible adoption. Au contraire, il suffit de consulter la liste des logiciels déclarant l’utiliser (http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal) pour s’en rendre compte ! On y croise de nombreux logiciels Open Source et des acteurs majeurs du monde propriétaire (ArcGIS d’ESRI notamment). Finalement, beaucoup de personnes utilisent GDAL/OGR sans même en avoir conscience ! Cette large adoption est en particulier facilitée par la licence de type MIT/X qui est très permissive. Je repense aux mots d’Howard Buttler, membre du PSC : « Je considère GDAL comme la glibc/glibc++ du monde du logiciel géospatial. C’est ouvert, ça fournit les fonctionnalités de base. Je ne peux pas comprendre comment quelqu’un pourrait faire quoi que ce soit sans lui » (voir http://en.wikipedia.org/wiki/GDAL pour la citation en VO).

Cet avis n’engage que moi, mais je doute qu’aucun des contributeurs actuels de GDAL/OGR n’ait vraiment comme objectif la création d’une interface graphique intégrée officiellement au projet. Bien sûr, l’avenir pourrait me donner tort. GDAL/OGR est avant tout une bibliothèque logicielle destinée à faciliter l’accès aux données géographiques. Si le projet fournit également des utilitaires en ligne de commande ou des scripts Python permettant l’interrogation, la conversion et les manipulations de base, ils sont avant tout une illustration des possibilités de la bibliothèque. La séparation entre bibliothèque (non graphique) et interface graphique répond à un des préceptes de la philosophie UNIX : faire en sorte que chaque programme fasse une seule chose et la fasse bien. Avec plus de 130 formats raster et vecteur gérés, GDAL/OGR domine sans partage sa niche dans le monde Open Source. Je dirais donc que, de part sa nature, GDAL/OGR est avant tout destiné aux développeurs et aux utilisateurs n’ayant pas peur de se frotter à la ligne de commande, ce qui n’a rien d’insurmontable pour peu qu’on prenne connaissance de la documentation… (petit clin d’oeil à sa traduction française : http://georezo.net/wiki/main:logiciels:gdal_ogr)

Interface graphique d'ogr2gui

De toute manière, outre les logiciels se reposant sur GDAL/OGR pour la visualisation de données, il existe de nombreuses interfaces graphiques aux outils en ligne de commande de GDAL/OGR : ogr2gui (http://www.inventis.ca/ogr2gui/index_en.htm), et surtout de nombreux greffons pour QuantumGIS comme l’outil de géoréférencement, le convertisseur de couches OGR, ou le tout nouveau greffon « GdalTools-plugin » (https://trac.faunalia.it/GdalTools-plugin/) pour simplifier l’utilisation des utilitaires de GDAL, etc. De mon point de vue, QGIS est en train de s’imposer comme une des interfaces graphiques de référence pour GDAL/OGR et c’est dans cette voie-là que j’orienterais les personnes souhaitant développer les interfaces graphiques pour GDAL/OGR. Quant à ceux qui ont besoin de réaliser des traitements évolués sur les données géographiques, ils peuvent se tourner vers GRASS, OSSIM, OTB par exemple.

5. Comment perçois tu l’effort du monde de la géomatique open source pour lire les formats propriétaires par rapport aux efforts du monde propriétaire pour lire les formats plus ouverts ou ceux de leurs concurrents ?

Qui dit format propriétaire dit souvent utilisateur dépendant d’un vendeur. Il est donc évidemment tentant pour certains acteurs du monde propriétaire de continuer à utiliser des formats fermés, mais devant la montée d’alternatives libres crédibles, je pense toutefois que l’avenir est à une utilisation accrue
de formats et protocoles interopérables. L’OGC est un des acteurs contribuant à cette tendance.

Quant à l’effort du monde de la géomatique Open Source pour lire les formats propriétaires, il répond au besoin pragmatique de sortir des situations où les utilisateurs sont parfois piégés avec les formats propriétaires. Mais il y a des situations où l’opposition Open Source / propriétaire doit être nuancée.
Prenons par exemple le cas du format JPEG2000. Les spécifications de ce format sont certes libres, mais il faut reconnaître que les implémentations les plus performantes passent actuellement par des logiciels propriétaires. De ce point de vue, GDAL ne fait pas de « politique » puisqu’il s’interface avec pas moins
de 4 implémentations différentes : propriétaires comme libecwj (Erdas), GeoSDK (LizardTech), Kakadu, ou libre comme Jasper.

Les paradoxes ne manquent pas : je pense notamment à ESRI qui a contribué récemment à des modifications dans le code source de GDAL (http://trac.osgeo.org/gdal/wiki/2009_ESRI_Merge), mais qui en même temps tarde à fournir les spécifications ou une API Open Source pour son format propriétaire, « file-based geodatabase » (FGDB). C’est finalement aux utilisateurs d’exiger des solutions interopérables de la part de leurs fournisseurs.

Merci Even !

Souscrire aux commentaires de cet article