Python: géospatial, dialectes (standard, pour ESRI, pour FME, pour GvSIG etc.) et incompréhensions...

Python a beaucoup de succès dans le monde SIG et tout amateur de Python devrait s'en réjouir, et ce titre peut paraitre bizarre à certains. Pourtant, c'est une réalité.

Tout d'abord, un petit résumé s'impose. Python existe sous plusieurs implémentations:

• En C, c'est le Python standard (ou « C Python »), qui s'exécute dans un environnement C,  avec plusieurs versions encore utilisées (en gros depuis la 2.3 jusqu'à la 2.7, sans parler de la 3.x qui marque une rupture);
• En Java, c'est Jython qui s'exécute dans une Machine Virtuelle Java (JVM). Le Jython 2.5.x , équivalent au Python 2.5.x est la dernière version;
• En Dotnet, c'est  IronPython qui s'exécute dans l'environnement NET. Il en est à sa version 2.6;
• il y en a d'autres, mais moins utilisées, comme Stackless Python ou PyPy.

Le plus connu et le plus utilisé est évidemment le Python standard avec toutes ses bibliothèques/modules.

Parmi les SIG qui l'utilisent, il y a lieu de faire une différence:

• il y a bien entendu les SIG de l'OSGeo, Quantum GIS ou GRASS GIS, qui l'utilisent pour leur interface ou pour les extensions avec la particularité que leurs modules propres (qgis ou grass) peuvent être appelés depuis l'environnement standard. Ils ne sont donc pas limités à un usage dans l'application. Par exemple, desktopgisbook.com/Creating_a_Standalone_GIS_Application_1 montre comment créer une application Python autonome en se basant sur le module qgis. L'implémentation est aussi utilisée avec Mapserver ou dans les frameworks web géospatiaux comme Django, TurboGears ou Mapfish.
• Il y a ceux qui utilisent un module lié à un logiciel généralement payant (comme ArcGis, Mapinfo, FME ou Manifold) et dont les scripts sont généralement conçus pour être utilisés à l'intérieur de l'application. Si l'on veut les utiliser dans un terminal, c'est possible, mais il faut l'application de base. Il manque des modules importants à ces distributions puisqu'elles ne les utilisent pas (Matplotlib, SQLAlchemy, par exemple) et que la majorité des utilisateurs, pour qui ce n'est qu'une boîte à outil supplémentaire, ignorent tout de setup.py ou easy_install.

D'autres utilisent Jython comme GvSIG, Geoserver ou Geotools. Ils fonctionnent dans une machine virtuelle Java et ne sont pas directement connectables avec le Python standard (par exemple, il leur sera impossible d'utiliser des modules écrits en C pour le Python standard comme GDAL, numpy, Scipy,  et vice-versa). C'est aussi le cas avec IronPython et .NET.

Sur Windows,  le module Pywin (qui utilise com) permet d'en "scripter" quelques-uns. Manifold, lui, accepte les scripts Python standard et IronPython (www.manifold.net/doc/scripts.htm)

Pourquoi alors dialectes ?

En pratique, il est facile de le constater, car les gens s'ignorent.

• Un programmeur Python ne peut être qu'horrifié lorsqu'il examine certains scripts pour Arcgis, proposés par des blogs ou par le feu site arcscripts.esri.com/, remplacé par resources.arcgis.com/fr, qui traduisent une pauvreté et/ou une méconnaissance du langage. Mais quelque part, c'est de l'art, lorsque l’on voit les efforts que font certains pour réécrire péniblement, par exemple, des parseurs de fichiers XML Arcgis. C'est comme s'ils ignoraient que le travail a déjà été fait depuis longtemps et qu'il existe de nombreux modules XML, à commencer par Elementtree présent dans la distribution standard qui leur est proposée (Python 2.5.x). Honnêtement, on se croirait quelques fois revenus à la préhistoire de Python, mais la situation évolue en mieux peu à peu.
• De la même manière, ces utilisateurs sont complètement désarçonnés lorsque des programmeurs vont leur parler de décorateurs, de "list comprehension" ou de modules comme GDAL ou Shapely, puisque fondamentalement ils n'ont pas besoin de ces éléments pour faire tourner leurs scripts et n'en voient pas l'utilité. 

L'incompréhension est donc presque totale, mais on peut distinguer 3 types d'utilisateurs

1. l'utilisateur moyen dont le seul but, s'il se lance dans Python,  est de faire un script qui fait ce qu'il veut dans le programme utilisé et ne se préoccupe pas d'autre chose comme du style de programmation. Il ne se base généralement que sur les modes d'emploi de son logiciel. L'important est que ça « marche », quels que soient les moyens. Il n'a généralement pas le temps de faire plus, sauf s'il se lance dans la publication de son script qui sera détaillé à l'extrême, mais « mal foutu » pour les utilisateurs suivants. Ceci le conduit à poser des questions du genre « Arcgis 9.3.1: Python Question - how do I extract a part of a string » sur « gis.stackexchange » (gis.stackexchange.com/questions/4748/python-question-how-do-i-extract-a-part-of-a-string);
2. l'utilisateur plus curieux, qui dans le but d'optimiser ou d'améliorer son script va peu à peu s'intéresser à Python et à ses nombreuses spécificités. Il commence à s'intéresser au langage et le « détache » du logiciel utilisé;
3. l'utilisateur puriste Python (selon divers degrés)  qui n'utilise généralement pas d'application. Les plus « purs » estiment que le seul bon script est un script qui respecte les règles « pythonesques » (traduction libre de pythonic)  comme recommandées par :  python.net/~goodger/projects/pycon/2007/idiomatic/handout.html ou eikke.com/how-not-to-write-python-code/ .

Ces 3 positions sont parfaitement justifiées et défendables suivant le cas où l'on se place. Les problèmes vont néanmoins surgir lorsqu'un utilisateur curieux ou puriste va proposer des modifications sur un script fait par un utilisateur moyen ou une nouvelle manière d'aborder le problème avec des éléments extérieurs à la « boîte » installée par son logiciel.  Le cas est particulièrement crucial si l'on essaie de poster des scripts non standards sur des sites comme celui d'ESRI, puisque celui qui va le télécharger n'est pas supposé savoir qu'il doit installer autre chose en même temps, il doit directement être fonctionnel et c'est bien comme ça.  Cependant, c'est fort embêtant pour les développeurs Python car aucun module ne peut être installé de cette manière.

Alors que faire ? Comment concilier ces aspects ?  Au vu de la puissance financière d'entreprises comme ESRI, les développeurs Python ont très peur que l’équation

Python + SIG = ESRI

devienne une réalité alors que les développements dans le domaine datent de bien avant que les firmes commerciales commencent à s'y intéresser. Le risque est un appauvrissement de Python utilisé dans le géospatial. Le problème ne se pose pas dans d'autres domaines.

La situation évolue pourtant peu à peu. Des sociétés comme ESRI ou FME commencent à faire des efforts pour favoriser la connaissance générale de Python (non plus limitée à l'utilisation de leur module propre), ce qui ne peut qu'être bénéfique pour eux.

Des blogs comme ceux de Sean Gillies essaient d'expliquer comment « bien écrire » en Python avec des exemples pour chaque logiciel et il montre surtout comment une bonne connaissance de Python permet d'optimiser n'importe quel script pour n'importe quel logiciel.

• sgillies.net/blog/951/python-idioms-for-gis-education/
• sgillies.net/blog/952/iterators/
• sgillies.net/blog/953/iterators-again/
• sgillies.net/blog/955/python-gis-features/

Ces blogs ne sont pourtant pas connus des utilisateurs d'une application SIG puisqu'il n'y a aucune référence explicite dans leurs titres.

Du coté des blogueurs ESRI ou FME, aussi les choses changent, car ils réclament des changements pour que le langage devienne plus standard, plus « pythonesque » comme le déjà cité:

• michalisavraam.org/2010/02/7-wishes-for-the-new-geoprocessor/.

Mais du côté du monde Open Source, il faudrait aussi que les choses bougent. Tout y est disséminé, sans coordination, voir même de la concurrence. Il n'y a aucun site fédérateur comme l'OSGeo (dont certains font partie).  D'où l'appel « Where's the book » de Sean Gillies, qui exprime bien le problème ( sgillies.net/blog/932/wheres-the-book/)

"To most GIS programmers "GIS with Python" means ESRI software scripting
now with Python instead of Avenue or AML. If there isn't an ESRI Press
book on scripting with Python already, there will be soon, but it'll be
bound to proprietary software. Software that's "free" to use in the U's
computer lab, but not free to use out in the real world or on the
internets. And it won't cover free and open source GIS tools. The seedy side
of GISville could be tackled in an "Open Source GIS with Python", perhaps, 
but even this is a fragmented place with many competing platforms."

(GISville = www.gis.com/  d'ESRI)

Une première tentative vient de sortir: « Python Geospatial Development » chez Packt Publishing (www.packtpub.com/python-geospatial-development/book) disponible dans divers formats, dont le pdf (25,49 EUR pour le pdf seul)

Ce livre aborde d'une manière très claire et détaillée l'utilisation de  GDAL, de OGR, de Pyproj, de Shapely ou de Mapnik, les liaisons avec les bases de données comme PostGIS, MySQL, Spatialite et l'utilisation de Django - GeoDjango (3 chapitres pour expliquer et créer une application complète). Tous les exemples sont téléchargeables. La table des matières est consultable à www.packtpub.com/toc/python-geospatial-development-table-contents.

Evidemment, constateront certains, il manque des choses (comme MapFish et tout ce qui n'est pas abordé) et ils vont donc s'empresser de critiquer l'ouvrage... Mais à mon avis, c'est un premier effort louable.

Pour moi, qui ne suis pas sur Windows et n'utilise aucun de ces SIG monosystèmes, mais qui aime beaucoup Python, le problème ne se pose pas, mais je continue à chercher, en apprenant, tout en espérant...

 

Site officiel : Jython
Site officiel : IronPython
Site officiel : FME
Site officiel : Manifold
Site officiel : Pywin
Site officiel : OSGeo