Sobre Python, módulos espaciales, programas SIG y controversias

Desde su adopción reciente en ArcGIS, Python tiene mucho éxito en el mundo de los SIG y cualquier aficionado a Python debería alegrarse, y este título puede parecer extraño para algunos. Sin embargo, es una realidad.

¿En primer lugar, qué es Python y qué relación tiene con los programas SIG?

• Es un lenguaje de programación de propósito general, Open Source, orientado a objetos, que también puede utilizarse para el desarrollo web (ver Qué es Python).  Permite realizar un montón de cosas en su versión estándar (como instalado):

Gracias a xkcd por dejar que la gente utilice sus imágenes para su propio uso.

• Es multiplataforma (funciona sobre Windows, Linux, Mac OS X, varios Unix, pero también Android, iPhone, etc.), y salvo raras excepciones, los scripts, simples ficheros texto, son universales (funcionan del mismo modo, independientemente del OS), lo que nos es le caso de Visual Basic, VB scripts y otros que son monoplataformas (Windows only);
• No tiene nada que ver con las aplicaciones SIG. No es un lenguaje de macros o de script de una aplicación particular, como Avenue para ArcView 3.x, por ejemplo, y el área de los SIG no es mas que uno de los usos de Python (con Google, YouTube, Pixar, Yahoo, Sony y muchos más). Sólo hace falta visitar sitios como:
  • Python sucess stories
  • Applications Written in Python
  • Applications with Python Scripting
  • o el “Planet Python” (http://planet.python.org/ ) para darse cuenta;
• La posibilidad de usar módulos/bibliotecas (numerosos), que añaden funciones adicionales a la instalación estándar, permite manejar cualquier tipo de datos y/o comunicar con la mayoría de los programas (desde Oracle o PostgreSQL pasando por Microsoft Office y otros). Estos módulos pueden ser desarrollados en Python pero también en C, en Java o en C#. El lugar de referencia de estos módulos es PyPI, el Python Package Index (http://pypi.python.org/pypi);
• ArcPy o PyQGIS, por ejemplo, no son mas que unos módulos particulares, entre otros, para el tratamiento de datos de ArcGIS y de QGIS, nada más, nada menos;
• Si se quieren tratar otros tipos de datos, es muy fácil encontrar un módulo adecuado (XML, Microsoft Excel, Oracle, gráficos, etc). No se tratan con ArcPy o PyQGIS y no hace falta tampoco volver a inventar la rueda…
• Existen otros módulos para tratar los objetos espaciales (shapefiles, raster, bases de datos espaciales, etc.). No utilizan software SIG y no son ni mejores ni peores, solo diferentes. Nada impide usarlos para complementar los tratamientos de los módulos ArcGIS o QGIS (ver por ejemplo QGIS, visualización 3D de capas vectoriales con Python);
• No tienen nada que ver con el programa y es necesario instalarlos en el repertorio adecuado de la instalación Python (site-packages) y eso puede ocasionar muchos problemas para un usuario Windows. En general, programas como ArcGIS o QGIS instalan une versión con unicamente los módulos necesarios mientras que en Linux o Mac OS X, QGIS, por ejemplo, utiliza una de la versiones de Python instaladas.

¿Cómo aprenderlo?

Imagen sacada de http://www.itc.nl/Pub/study/Courses/C12-GFM-DE-07

• El que trabaja en geomática no es generalmente un informático y se ven muchas preguntas del estilo: “Quiero aprender Python para el software X”;
• El módulo  Python que permite la comunicación con este software es unicamente una “capa” adicional: añade nuevas funciones a la biblioteca estándar de Python;
• Querer aprender Python usando unicamente estas funciones adicionales es un poco reductor y conduce a varios problemas, aunque algunos desarrolladores de programas digan lo contrario, lo que es inusual, incluso ESRI, pero todo el mundo quiere llegar rápidamente a la solución…
• Parece más rentable tener una idea clara de lo que puede hacer Python, de su filosofía (cómo hacerlo sin necesidad de ir demasiado lejos) para luego aplicar estos conocimientos al uso del módulo X (si no se entiende el concepto de lista en Python, es difícil utilizar los cursores utilizados por ArcPy, por ejemplo. Además, otros módulos utilizan también cursores);
• Esto permite en primera instancia, entender lo que hace un script, eventualmente modificarlo o buscar sobre Internet las soluciones a sus problemas (hay miles de tutoriales o scripts para manejar todo y nada impide utlizarlos,  copiarlos y/o modificarlos en lugar de romperse la cabeza…);
• Lo más importante es que el script funcione bien para lo que se quiere hacer, incluso si un programador lo encuentra mal hecho (hay mejores maneras, etc.). Todo el mundo no es un programador y el tiempo es valioso. Pero el tiempo para aprender algunos de los trucos de los programadores es también valioso. Es la manera de aprender poco a poco.

¿Cuáles son los dialectos-implementaciones de Python?

Python existe en varias implementaciones:

• En C, es Python (o “C Python”), que se ejecuta en un entorno C;
• En Java, es Jython que se ejecuta en una máquina virtual Java (JVM);
• En DotNet, es IronPython que se ejecuta en el entorno NET;
• Hay otros, pero menos utilizados como Pypy.

El más conocido y más utilizado es, por supuesto, Python, con varias versiones aún usadas (desde la 2.4 a la 2.8, sin mencionar las 3.x que marcan una ruptura) con todos sus módulos/bibliotecas. Un script en Python puro funciona de la misma manera en todas la implementaciones pero, por ejemplo, Jython no puede utilizar módulos escritos en C como GDAL o Numpy y, de la misma manera, Python no puede utilizar módulos escritos en Java (de Jython). La situación es la misma con IronPython.

¿Qué son las módulos geoespaciales?

Son módulos que permiten tratar todos los objetos espaciales o hacer análisis sin necesidad de usar una aplicación. Los principales existen desde hace bastante tiempo y se utilizan desde antes de los que se utilizan en los programas SIG. Varios programas SIG los utilizan. No vamos a analizarlos aquí porque está fuera del alcance pero la gran mayoría de ellos son para Python y se pueden encontrar en Topic :: Scientific/Engineering :: GIS en el Python Package Index. Los específicos para Jython o IronPython son menos (los que no son escritos en Python puro).

¿Qué utilizan las aplicaciones SIG?

Las que utilizan Python:

Aquí, hay que hacer una distinción entre:

• Los  módulos abiertos que no son vinculados a una aplicación como los de los programas del OSGeo, QGIS y GRASS GIS. Utilizan Python para sus interfaces o para la creación de plugins pero sus propios módulos (PyQGIS y GRASS script) se pueden utilizar fuera de la aplicación como en el shell Python o en Construcción de un visor de Shapefiles con herramientas libres de GeoTux, por ejemplo. Si se desea, también se puede utilizar PyQGIS en GRASS GIS y el inverso.
• Los módulos cerrados que no se pueden utilizar fuera de una aplicación particular como ArcPy con ArcGIS (o los de FME). Estos programas instalan sus proprias versiones de Python (pero QGIS para Windows también y el que instala ArcGIS, QGIS y GRASS GIS en Windows se encontrara también con 3 versiones de Python instaladas). Faltan muchos otros módulos importantes porque no los necesitan aunque sean útiles (como Matplotlib, Shapely o SQLAlchemy, por ejemplo). Para el que quiera utilizarlos, es muy difícil instalarlos posteriormente.

Las que utilizan otras implementaciones:

• Otros utilizan Jython como gvSIG, GeoTools o GeoServer.
• Manifold, por ejemplo, acepta scripts en Python y en IronPython (www.manifold.net/doc/scripts.htm).
• En Windows, el modulo Pywin (que utiliza com) permite tratar a algunos otros, como MapInfo.

Problemas e incomprensiones

El problema  principal proviene de la incomprensión entre los programadores Python y los usuarios de estos programas SIG: parecen dos mundos distintos.

• Un programador Python se queda generalmente horrorizado al revisar algunos scripts para los SIGs propuestos en los blogs. Reflejan una pobreza /o un mal conocimiento de Python. A veces los esfuerzos para realizar un tratamiento parecen arte, como el tratamiento de los ficheros XML, desconociendo los módulos para tratarlos, empezando por elementtree presente en la distribución estándar desde la version 2.5. Sinceramente, parece como volver a la prehistoria de Python, pero la situación está mejorando poco a poco.
• Inversamente los usuarios están completamente desconcertados cuando los programadores les hablan de decoradores, de lista por comprensión o de módulos como Shapely o GDAL, porque al final no necesitan estos elementos para ejecutar sus scripts y no ven su utilidad.

La  incomprensión es casi completa pero podemos distinguir tres tipos de usuarios:

1) El usuario cuyo único propósito, cuando utiliza Python, es realizar un script que hace lo que quiere en el programa utilizado sin preocuparse del estilo de programación. Se basa generalmente sobre lo que le propone el programa y nada mas. Lo importante es que funcione, sea cual sea la manera. En general, no tiene tiempo para hacer más, pero si quiere publicar su tratamiento, será un script con muchos detalles inútiles y mal hecho para los siguientes usuarios. Eso conduce a preguntas básicas como “¿Arcgis 9.3.1: Pregunta Python – ¿cómo puedo extraer una parte de un string?” en  gis.stackexchange.com/questions/4748/python-question-how-do-i-extract-a-part-of-a-string).

Imagen sacada de http://www.dedoimedo.com/computers/write-python.html

2) El usuario más curioso, que con el fin de optimizar o de mejorar su script se va a interesar a las características generales de Python, y separarlo poco a poco del programa utilizado.
3) El usuario “purista” Python (diversos grados) que por lo general nunca utiliza una aplicación y piensa que la única manera de programar es de de respectar las reglas “pythonescas” (traducción libre de pythonic) según lo que esta recomendado en papeles como python.net/~goodger/projects/pycon/2007/idiomatic/handout.html o eikke.com/how-not-to-write-python-code.

Imagen sacada de http://hackaday.com/2012/06/13/myhdl-python-programming-option-for-fpga/

Estas tres situaciones pueden justificarse y defenderse perfectamente según el caso. Pero los problemas van a surgir cuando un usuario curioso o purista va proponer cambios en un script realizado por un usuario del primer tipo, o utilizar otra manera de resolver el problema usando módulos que ne están en la “caja” del software instalado. El problema es crucial cuando uno quiere presentar un tratamiento, un script, para ArcPy, por ejemplo, usando un módulo que no esta en la “caja” de ArcGIS: ¿Cómo el usuario de ArcGIS que desea utilizar este script puede instalar el módulo si no conoce Python? Proponerlo como una extensión para ArcGIS no va a resolver el problema: los módulos Python no se instalan de esta manera, salvo excepciones.

¿Y cómo conciliar estas posiciones? Dado el poder de empresas como ESRI, los desarrolladores Python tienen mucho miedo de que la ecuación:

Python + GIS/SIG = ESRI

Imagen sacada de http://salemoregonrealestatehomes.com/2010/12/20/10-ways-to-search-for-homes-with-kids/

se convierta en la realidad  aunque, como se dijo, los desarrollos empezaron antes que las firmas comerciales se interesen en Python.

Pero la situación está cambiando poco a poco. Las empresas como ESRI o FME realizan muchos esfuerzos para promover el conocimiento general de Python (no limitado a la utilización de su propio módulo), lo que puede ser beneficioso para ellas. Algunas empiezan también a utilizar los otros módulos.

Blogs como el Sean Gillies (el creador del módulo Shapely) tratan de explicar cómo “programar bien” en Python con ejemplos para cada programa y enseñan, sobre todo, cómo un buen conocimiento de Python permite de optimizar cualquier script para cualquier programa.

• 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/

El problema es que estos blogs no son conocidos por los usuarios de los programas SIG porque no tienen una referencia explícita en el título.

Del lado de los blogeros ESRI, las cosas están también cambiando como en michalisavraam.org/2010/02/7-wishes-for-the-new-geoprocessor/ que pide cambios adecuados en los tratamientos.

Pero del lado del mundo OpenSource, también se necesita que las cosas cambien. Todo está disperso y sin coordinación, incluso con competencias. De ahí la llamada de Sean Gillies, “¿Dónde está el libro?” que resume bien el problema (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 GIS ville could be tackled in an “Open Source GIS with Python”, perhaps, but even this is a fragmented place with many competing platforms.“

Un primer intento ha sido publicado hace poco tiempo: “Python Geospatial Development” (www.packtpub.com/python-geospatial-development/book) de Erik Westra:

Este libro cubre de una manera muy clara y detallada el uso de GDAL, de OGR, de Shapely, de Pyproj, de Mapnik, enlaces con las bases de datos como PostGIS, MySQL, y SpatiaLite, y las utilizaciones de Django – GeoDjango. Todos los ejemplos pueden ser descargados y la tabla de contenido está disponible en https://www.packtpub.com/product/python-geospatial-development-third-edition/9781785288937.

Por supuesto, algunos notarán que faltan muchas cosas y se apresuraran a criticar el libro. Pero en mi opinión, es un primero esfuerzo que vale la pena.