Skip to Content

Nous adressons toutes nos pensées à la famille de notre ami Jérôme !

http://www.forumsig.org/showthread.php/43488-Disparition-de-Phoenix

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


python

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.

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é:

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

Commentaires

Quelques ressources en sus

voir le billet http://gislounge.com/python-and-gis-resources/ pour quelques ressources (en anglais...) en plus

 

 

Formation - Formation - Formation

Sujet intéressant qui pose plus gobalement selon moi la question de la formation pour les géomaticiens-cartographes-géographes-etc.
Car la fin du message le dit : nous pêchons bien simplement par manque de formation point.
En ce qui me concerne chaque fois que je demande où et comment se former à tel ou tel sujet de la géomatique personne ne répond. Pas étonnant donc que chacun fasse "sa géomatique"... non mutualisable de fait.
Il suffirait d'être un peu plus ouvert, au lieu de toujours diviser le monde en 2 catégories : les bons (ceux qui ont sû sentir le vent et se former tout-de-suite à l'algorithmie et à la programmation) et les méchants (horribles géographes qui se disent géomaticiens parce qu'ils savent faire 3 clics avec leur logiciel grâce à des programmes qu'on a bien voulu développer pour eux).
C'est un constat personnel, mais j'ai toujours penser que la transmission est essentielle et qu'il n'y a pas en vérité de baisse de niveau.
Dîtes-nous où et comment il est possible de se former et on le fera, mais pas de l'auto-formation, des blogs ou des forums : du concret, des " vraies" formations, avec des vrais gens, des vrais professeurs, avec une réelle envie de transmettre, et où on peut faire des exos, corriger ses erreurs, comprendre sereinement les choses.
Mais peut-être cela n'existe-il plus effectivement ? La géomatique ne serait- elle pas finalement tout simplement malade de sa propre philosophie, orientée sur le tous virtuel, le tout informatique ?
Espérant que précisément ce commentaire (un peu long) ne restera pas sans réponse dans ce débat

formations et métiers ?

J'ai hésité à répondre au commentaire précédent mais je vais tenter de donner mon avis sur les deux du coup :

Je vois les choses un peu différement, on peut imaginer des métiers différents, géomaticien on peut penser que sous ce terme on regroupe plusieurs métiers et que donc une des branches serait le développements d'outils SIG, et cela sans pour autant être informaticien.

Si je reprends les stades dont nous parle Martin, je pense me situer au 2ème, loin d'être un puriste python, je le connais peu mais suis très intéressé par celui ci, d'autant plus difficile d'en devenir un puriste vu que je jongle entre différents langages en fonction du projet. Mais finalement est ce si important, bien sur c'est mieux de faire des choses propres, mais selon l'objectif, arriver à faire ce qu'on souhaitait, c'est quand même déjà pas mal.

Enfin, pour le problème de la formation, la première chose que je peux dire c'est que nous, l'équipe du forumSIG, de l'annuaireSIG et du portailSIG essayons à notre petite mesure d'apporter une petite pierre à cela, mais nous sommes des bénévoles et nous ne monterons pas telle ou telle formation. Et peut être que nous n'avons pas les réponses pour vous renseigner sur les formations existantes. Ceci dit je vous encourage à parcourir les offres de formations existantes, chaque éditeur en propose, ainsi que des SSLL où vous pourrez trouvez des formations de ce type, on peut en particulier se référrer à cette page : http://wiki.osgeo.org/wiki/Offres_Formations_fr et d'autres organismes spécialistes de la formation SIG, en faisant une recherche sur le forumSIG http://www.forumsig.org/forumdisplay.php?f=15 ou en parcourant les pages dédiées aux formations sur georezo http://georezo.net/wiki/formation:start , ainsi que l'annuaire commun georezo - petit bazar cartographique - forumSIG http://www.annuairesig.org/formation-c-3.html il y a quand même de quoi faire.

Si vous souhaitez des formations plus longues renseignez vous dans les différentes universités, j'ai pour ma part fait un DESS en géomatique dans lequel nous abordions l'algorithmique et la programmation (il s'agit du master SIGMA, autant faire de la pub, je l'ai trouvé excellent, mais d'autres formations de ce type proposent le même genre d'enseignement)

Alors par conséquent je ne partage pas votre avis quand vous dites : "La géomatique ne serait- elle pas finalement tout simplement malade de sa propre philosophie, orientée sur le tous virtuel, le tout informatique ?" la géomatique n'a de sens que si elle répond à un besoin et de préférence que ce besoin soit bien réel.

Oui les formations existent, mais en fonction de ce que vous souhaitez elles répondront plus ou moins à votre besoin.

Mais je le répète, je ne crois pas non plus qu'il soit obligatoire lorsqu'on se dit géomaticien d'être un as du développement, il s'agit de choix ...

Personnelement je trouve mon poste actuel très intéressant, je fais essentiellement du développement d'outils ou de sites carto, je ne suis pas informaticien, et je pense que c'est intéressant, cela me permet de bien connaître les outils géomatiques existants, de pouvoir développer des choses "simples" manquantes et de faciliter mes échanges avec de vrais informaticiens lorsque les problèmes me dépassent. Mais est il si nécessaire de séparer si strictement ces métiers là.

Enfin je vais voir pour rajouter un champ dans les commentaires afin que vous puissiez laisser votre prénom, ce sera plus sympathique (je pensais l'avoir fait mais non)

+1... C'est ce que

+1...
C'est ce que j'exprimais en partie dans mon premier commentaire (http://www.portailsig.org/content/python-geospatial-dialectes-standard-p...)

La lecture de "Comment je suis devenu géomaticien" (http://www.lecavalierbleu.com/f/index.php?sp=liv&livre_id=220) ne dit de plus pas autre chose.

La communauté géomatique n'est globalement pas de formation de développeur. Néanmoins, l'outil informatique est très présent (rangeant même parfois dans certaines petites structures et collectivités le géomaticien dans un poste également d'informaticien effectuant la maintenance pc, réseau, ... de premier niveau).
De plus, sortir de clics sur boutons (traitements batch par exemple, sans aller jusqu'à créer sa fonction qui va bien) demande de s'investir dans le logiciel utilisé et dans le langage employé par ce logiciel.
Et là, on se heurte aux bonnes pratiques nécessaires pour finaliser le projet de développement. Bonnes pratiques qui ne s'acquièrent pas en quelques jours...

Géomaticien ou informaticien ?

Merci pour ce sujet très intéressant ; pour ma part, je suis avant tout géographe, et effectivement, je ne possède pas de notions en algorithmique. Je gère le SIG d'une collectivité, et comme je le dis toujours, les aspects ici évoqués sont plus du ressort d'un informaticien que d'un géomaticien. vous me direz, tout dépend de ce qu'on entend par géomaticien. Pour ma part, je m'attache plus aux 3 premières lettres !
Je me revendique donc comme "utilisateur moyen", et encore : on m'a toujours dit que Python était un langage "simple". Oui.. Enfin, pour un informaticien, sans doute !

Reste que cette problématique, à mon avis, ne sera jamais résolue, à moins que l'on comprenne qu'il est indispensable de combiner les compétences de chaque métier (certains l'ont compris, heureusement). Je ne serai jamais un pro du développement comme un informaticien ne sera jamais un géographe expert...

Moi, c'est l'inverse, je ne

Moi, c'est l'inverse, je ne suis ni géographe, ni géomaticien, ni informaticien de formation, mais je me suis intéressé à la programmation bien avant les SIG, C, avec une petite formation à l'université, Basic, Perl et maintenant essentiellement Python.
Mais ça ne m'intéresse que pour l'aspect fonctionnel, c'est-à-dire que ça me serve à quelque chose : comment programmer pour résoudre un problème précis et surtout comprendre comment ça marche. Je vois ça comme un défi et je pense qu'à tout problème, il y a une solution plus ou moins simple en programmation.

J'ai donc abordé les SIG avec cette optique, ce qui m'a conduit à me méfier des "boites noires" c.a.d., je pousse sur un bouton et j'obtiens un résultat sans savoir ce que fait exactement la commande, quelle est la part d'erreur éventuelle qu'elle peut provoquer dans le résultat et sur quoi elle est basée. J'ai en effet vu beaucoup de dégâts provoqués par ces "boîtes noires" qui poussent certaines personnes à vouloir expliquer par des causes naturelles ce qui n'est dû qu'à des artefacts ou des erreurs informatiques.

Dans mon boulot, je me sers de Python pour beaucoup d'autres choses et de ce fait, j'accorde plus d'importance au langage Python lui-même qu'à son utilisation dans un SIG.
Comme ça se sait, on m'envoie des scripts Python pour ArcGIS qui ne tournent pas (de la part de "spécialistes" ArcGIS) et j'ai été interloqué. De même, certains blogs liés à l'environnement ESRI sont remplis de scripts "mal foutus" mais on me répond à ça que je ne connais pas ArcGIS, que je ne comprends rien et que, de toute manière, ça marche.
Je me dis qu'une meilleure connaissance du langage permettrait d'éviter bien des tracas et j'ai donc pris contact avec Sean Gillies qui poursuit le même objectif (mais lui est informaticien de formation).

Martin Laloux pour la réponse

Martin Laloux pour la réponse précédente

Pas faux

On pourrait rajouter que selon l'enquête Géorezo (http://georezo.net/wiki/main/formetiers/enquetes), le géomaticien français est généralement pauvre, de formation, en informatique. Comprendre algorithmique, génie logiciel, bonnes pratiques de développement, ... C'est ce que démontrait et tendait à gommer les présentations http://www.portailsig.org/content/le-forumsig-present-sig-2010.

De fait, ce manque de compétence initial range quasi d'avance le géomaticien dans la première catégorie de ton analyse, avec des possibilités de passer dans la seconde à force de pratique.

Dans mon cas personnel, après 2,5 ans de .Net quotidien, je commence seulement à me sentir dans le pavillon de la troisième.

Ne pas oublier également que comparativement à Java ou .Net, Python n'est pas pleinement porté par un des géants du secteur informatique, ce qui brouille effectivement le langage

Poster un nouveau commentaire

Le contenu de ce champ sera maintenu privé et ne sera pas affiché publiquement.