Skip to Content

Répondre au commentaire

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).

Répondre

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