ANEXO AL CAPÍTULO 6:

DESCRIPCIÓN TÉCNICA DE LOS

FLUJOS DE TRABAJO PRP Y
MODPLAN

Blas M. Benito de Pando

19 de septiembre de 2009
Introducción

En este documento describo en detalle los flujos de trabajo PRP y MODPLAN.

Está pensado para aquellos que quieran entender el funcionamiento de ambos flujos, ya
sea para utilizarlo, o mejorarlo. Ambos flujos de trabajo están compuestos por multitud
de elementos (parámetros, directorios, scripts, actores...) y explicar su funcionamiento
no es sencillo. Para facilitar la identificación de los distintos elementos he adoptado un
código de colores:

CARPETA (o DIRECTORIO, los uso indistintamente).

PARÁMETRO

VARIABLE

ACTOR DE KEPLER COMPUESTO

ACTOR DE KEPLER

SCRIPT

MAPA RASTER O VECTORIAL EN GRASS

El código de colores le da al texto un punto de estridencia, pero son los que proporciona
el editor de texto en el que trabajo. Creo que mejora en cierta medida la identificación de
los elementos. Para mejorar aún más la comprensión del texto, aunque muestro imágenes
de las distintas secciones del flujo, es conveniente tener abiertos PRP y MODPLAN
en Kepler, y tener a mano los scripts que están en el anexo digital.
Este texto no pretende ser un manual de uso, sino una pequeña introducción para
facilitar la toma de contacto con ambos flujos de trabajo.

1
Configuración del entorno de
trabajo

El flujo de trabajo tiene una serie de requerimientos imprescindibles que detallo a

continuación:
Sistema Operativo Linux (probado en Ubuntu Hardy Heron y Ubuntu Jaunty
Jackalope).
Java (versión 1.5 ó 6). Sobre el segundo, Kepler es más estable, pero aparece un
bug que en ocasiones bloquea el teclado. Sobre el primero este bug no aparece,
pero en ocasiones Kepler se cae sin motivo.
GRASS (versión 6.3.0; 6.4.0 para la versión 2 del flujo de trabajo): debido a
un bug, exige que se copie el script v.type.sh desde /grass/etc/gui/scripts a
/grass/scripts, para garantizar el funcionamiento correcto de la rutina v.type cuan-
do es llamada desde un script,.
R (versión 2.8.1 ó 2.9.1), con las siguientes librerías instaladas: vioplot, geneplot-
ter, RColorBrewer, reshape, Cairo.
Octave (versión 3.0.0).
OpenModeller (versión 0.7 ó 1.0): paquetes libopenmodeller, libopenmodeller-
algorithms, y openmodeller-console.
ImageMagick: programa libre de procesamiento de imágenes.
pdftk: programa libre de edición de ficheros pdf.
rpl: aplicación para reemplazo de texto en múltiples ficheros.
gawk (requerido en la versión 2 del flujo de trabajo): lenguaje de procesamiento
de texto plano.
Kepler (versión 1.0).
Un directorio dedicado para el proyecto (en adelante, DIRECTORIO RAIZ), que
contiene los directorios siguientes:

2
• PROGRAMAS, que contiene los scripts, archivos de configuración y flujos de
Kepler necesarios.
• PRESENCIA_SHP, que contiene los shapefiles con la presencia de las es-
pecies, nombrados con el nombre científico de la especie, sustituyendo los
espacios por caracteres “_”.
• VARIABLES, que contiene las variables ambientales usadas para calibrado y
proyección de modelos en formato BIL (Band Interleaved by Pixel). Es muy
importante que la resolución en x e y sean exactamente iguales (es un
requerimiento de MaxEnt).
• Un directorio de mapas de GRASS, con una localidad configurada para la
región de trabajo, en un sistema de referencia UTM (es un requerimiento
de la rutina de Octave que calcula las distancias entre puntos de presen-
cia). Se requieren dos mapsets, uno para la evaluación de modelos (map-
setEVALUACION) y otro para la proyección (mapsetPROYECCION).

3
Preparación de los registros de
presencia

Los puntos de presencia los prepara el flujo de trabajo PRP (Preparación de Registros
de Presencia) (ver Figura 1). El flujo tiene una serie de parámetros que deben ser
rellenados por el usuario:
DIR_RAIZ: La ruta al directorio de trabajo.
DIR_USER: La ruta al directorio de usuario .
DIR_GRASS_EV: La ruta al mapset EVALUACION.
DIR_GRASS_PR: La ruta al mapset PROYECCION.
RESOLUCION: Resolución de trabajo deseada para los mapsets de GRASS. Lo
ideal es seleccionar la resolución nativa de las capas de variables ambientales. Si se
selecciona una menor, se debe tener en cuenta que el método rápido de remuestreo
de GRASS utiliza un algoritmo de vecino más próximo que compromete la calidad
de los resultados.
MIN_DIS: Distancia mínima entre pares de coordenadas de presencia de la especie.
Idealmente, el doble de la resolución de trabajo, para garantizar la presencia de al
menos una celda vacía entre punto y punto.
PARTICION: Porcentaje de los registros de presencia que se utilizará como con-
junto de evaluación. Lo habitual es utilizar entre un 25 y un 50 por ciento de los
puntos con este propósito.
MIN_PRES: Número mínimo de registros de presencia necesarios para que una
especie pueda pasar a la fase de modelado. Un número mínimo conservador es 30.
El flujo de trabajo está formado por tres actores, dos de ellos compuestos:
PRECONFIGURACION (ver Figura 2): Se encarga de preparar los directorios de
trabajo, mover los ficheros necesarios y configurar un fichero de variables generales
para los scripts de bash del flujo. También genera un listado con los shapefiles del
directorio PRESENCIA_SHP, los cuenta, y pasa el resultado numérico al siguiente
módulo, predeterminando el número total de iteraciones.

4
PREPARA_XY (ver Figura 3): Este actor compuesto itera un número de veces
igual al parámetro NUM_ESPECIES, proporcionado por el actor anterior. Está
compuesto por tres actores:

• CONFIGURA_VARIABLES (ver Figura 4): Configura un fichero de va-

riables propias de cada iteración, y lanza las iteraciones de PREPARA_XY
cada vez que lee una ruta a un fichero shp de la lista de shapefiles. Es el
motor que permite iterar al flujo completo una vez por cada especie de la
lista.
• PREPARA_COORDENADAS (ver Figura 5): Este módulo ejecuta las
siguientes tareas:
◦ Actor EXTRAE_XY: Transforma los polígonos de presencia en pares de
coordenadas mediante un batch-job de GRASS (2 ejecuta EXTRAE
COORDENADAS) que, rasteriza los polígonos a la resolución de tra-
bajo, vectorización de nuevo los polígonos rasterizados pero a una geo-
metría de puntos, y exporta los pares de coordenadas resultantes a un
fichero de texto.
◦ Actor compuesto PROCESA_XY, se encarga de las siguientes tareas
mediante la ejecución de un script de Octave (3 PROCESA COOR-
DENADAS):
◦ Disminución de la autocorrelación espacial de las muestras: Las coor-
denadas se procesan para aplicar el criterio de distancia mínima según
el valor del parámetro MIN_DIS. Un algoritmo programado en Octave
selecciona un punto, mide la distancia al punto más cercano, y si la dis-
tancia entre ellos es menor al valor de MIN_DIS, elimina el segundo,
y continúa el proceso con un nuevo punto. Cuando no puede encontrar
ningún punto con una distancia inferior al umbral, cambia al siguiente
punto y continúa el proceso.
◦ Partición aleatoria de los datos: Separación al azar de las coordenadas
en dos conjuntos (calibrado y evaluación), según el valor del parámetro
PARTICION.
◦ Formateo de los ficheros de texto con las coordenadas para adaptarlos a
los requerimientos de MaxEnt y OpenModeller.
◦ Escribe listados de especies aceptadas y descartadas. Envía parámetros
al módulo que descarta las especies.
• DESCARTA_ESPECIES (ver Figura 6): Es una ramificación condicional
que envía los datos de cada especie a un directorio de especies aceptadas
(RESULTADOS) o de especies descartadas (ESPECIES DESCARTADAS)
según su valor de número de presencias sea mayor o menor que el parámetro
MIN_PRES.

5
Figura 1: Flujo de trabajo PRP. Está formado por dos actores compuestos que contienen
flujos de trabajo completos (ver Figuras 2 y 3). El actor PRECONFIGURACION solo
se ejecuta una vez. El actorLoop permite que PREPARA_XY se ejecute tantas veces
como le indica el valor NUM_ESPECIES.

Como resumen final, listo las entradas y salidas del módulo:

ENTRADAS:

• Directorio con ficheros shp de presencia de especies.

SALIDAS:

• Árbol de directorios de trabajo organizado.

• Coordenadas separadas según MIN_DIS, particionadas según el valor del
parámetro PARTICION, y debidamente formateadas para OpenModeller y
MaxEnt, guardadas en un directorio con el nombre de la especie.
• Especies separadas en aceptadas y descartadas según el valor del parámetro
MIN_PRES.

6
Figura 2: Actor compuesto PRECONFIGURACION. Se ejecuta una sola vez, y prepara
todo el entorno de trabajo.

7
Figura 3: Estructura del actor PREPARA_XY. El actor CONFIGU-
RA_VARIABLES envía el nombre de la especie a PREPARA_COORDENADAS.
Este ejecuta la parte importante de procesamiento del flujo. Una vez terminada, envía
el número de presencias y la ruta en la que se guardan los resultados de la especie a
DESCARTA_ESPECIES.

8
Figura 4: Actor compuesto CONFIGURA_VARIABLES. Este actor escribe un fichero
de texto con valores de variables que serán necesarias en los scripts del flujo. Tiene un
sistema de control (actores COMPRUEBA_FICHERO e INTERRUPTOR) que impide
que el actor emita el nombre de la especie antes de que se complete la escritura del
fichero de variables. Solo cuando el fichero de variables existe se manda el nombre de la
especie al siguiente actor del flujo.

9
Figura 5: Estructura interna del actor compuesto PREPARA_COORDENADAS. Las
secciones principales están señaladas con rectángulos de color. Un actor fundamental es
BORRA_LINEA, que borra una especie de la lista de especies, permitiendo al flujo
empezar con una nueva especie en la siguiente iteración. El actor LISTAS_ESPECIES
es una expresión de R a la que se le introduce un listado con las especies y su número
de presencias. Devuelve dos listas, una con las especies que cumplen los criterios y otra
con las que no.

10
Figura 6: Actor compuesto DESCARTA_ESPECIES. Contiene una bifurcación
condicional. El actor Comparator compara el valor NUM_PRESENCIAS que le lle-
ga con el valor del parámetro MIN_PRES determinado por el usuario. Si el valor
de NUM_PRESENCIAS es mayor que MIN_PRES, se activa la ramificación ESPE-
CIE_ACEPTADA, y los datos de la especie se escriben en el directorio de resultados.
Si la comparación resulta negativa, los datos de la especie se escriben en el directo-
rio ESPECIES_DESCARTADAS. Este actor tiene su propio modelo de computación
implementado en el director DDF (dynamic dataflow).

11
Calibrado inicial, ensamblado y
evaluación

Los objetivos que cubre el flujo de trabajo en esta sección son los siguientes:
Calibrado de modelos según 8 algoritmos diferentes: Máxima entropía (ME), Dis-
tancia de Chebyshev (CH), Distancia de Mahalanobis (MH), Distancia de Man-
hattan (MN), Distancia Euclídea (EU), GARP (GA), Red Neuronal (NN), Support
Vector Machines (VM).

Ensamblado de los modelos calculando la media y la desviación estándar de la

idoneidad de los resultados de los distintos algoritmos.

Extracción de datos: distribución de valores, y comparación entre mediana y des-

viación estándar.

Evaluación estadística de los modelos, una en un ámbito local, determinado por

el rectángulo mínimo que acoge todos los registros de presencia de la especie, y
otra de ámbito global, para todo el territorio de Andalucía. El objetivo es testar
el funcionamiento de cada modelo sobre distintos ámbitos geográficos.

Representación gráfica de los resultados de la evaluación.

MODPLAN presenta dos parámetros comunes con el flujo PRP, y uno propio, llamado
PORCENTAJE_OMISION, que explicaré más adelante. El flujo consta de los siguientes
actores compuestos:

NUMERO_ESPECIES: Cuenta el número de especies que cumplen el criterio

de presencias mínimas establecido en MIN_PRES en el flujo PRP. Este número
se envía como parámetro al siguiente módulo, determinando así el número total
de iteraciones del proceso (una por cada especie) (ver estructura en Figura 8).
Además realiza otras tareas importantes para la sección del flujo que proyecta los
modelos (se explicarán detalladamente más adelante).

EJECUCION_MODELOS (Figura 9): Está a su vez compuesto por dos actores

compuestos:

12
Figura 7: Flujo de trabajo MODPLAN. NUMERO_ESPECIES solo se ejecuta
en una ocasión. Para garantizar que EJECUCION_MODELOS se ejecuta tan-
tas veces como especies deben procesarse, se coloca el actor Loop. El actor NUME-
RO_SELECCIONADAS muestra al usuario el número de especies que se van a procesar.

13
Figura 8: Actor compuesto NUMERO_ESPECIES. Este actor compuesto cuenta con
un sistema de control igual al observado en la Figura 6. El interruptor no deja pasar la
señal hasta que el actor REESCRIBE SCRIPT 13 ha terminado su tarea.

Figura 9: Estructura del actor compuesto EJECUCION_MODELOS. NOMBRE

ESPECIE pasa el nombre de la especie seleccionada a MODELADO, donde se usará
como un parámetro.

14
Figura 10: Actor compuesto NOMBRE_ESPECIE. El actor ITERADOR2 configura
su número de iteraciones según el valor de número de especies que llega desde NU-
MERO_ESPECIES (Figura 9). Cada vez queITERADOR2 dispara, el actor LEE_LISTA
lee un nombre de especie de la lista de especies seleccionadas (utilizando una orden de
Bash), enviándolo al siguiente actor. ESPECIE_EN_PROCESO muestra al usuario el
nombre de la especie que se está procesando.

NOMBRE_ESPECIE: Lee una a una las especies de la lista de especies selec-

cionadas. Por cada línea del fichero, lanza una iteración completa del siguiente
actor (Figura 10).

MODELADO (Figura 11): Es la sección del flujo que hace todo el trabajo im-
portante en esta fase.

Esta sección del flujo ejecuta las siguientes tareas:

Formateo de scripts para la ejecución de OpenModeller: OpenModeller requiere un
fichero de configuración con las rutas de las entradas y salidas, y los parámetros
del algoritmo. La primera sección del flujo prepara estos ficheros.

• Ejecución de los modelos. El actor EJECUTA MODELOS, genera los modelos

de distribución según los ocho algoritmos ejecutando el script 6 inicial MO-
DELOS EVALUACION. Cada modelo ejecutado produce dos resultados:
un mapa digital con extensión .asc, que se importa a GRASS, y un fichero
con la definición del modelo numérico.
◦ Ensamblado de modelos y exportación de mapas: El propio script 6 ini-
cial MODELOS EVALUACIONlanza el batch-job de GRASS llama-
do7 ejecuta MODELOS EVALUACION, que importa los resultados

15
Figura 11: Actor compuesto MODELADO: Sección que ejecuta y evalúa los modelos
iniciales. La variable ESP_SELECCIONADA muestra el nombre de la especie al resto
de actores. La primera sección rellena la cabecera del fichero de configuración para
OpenModeller. El actor UNE PARAMETROS la une con los ficheros de parámetros de
16
los algoritmos. EJECUTA MODELOS usa el fichero resultante para generar los modelos.
 de MaxEnt y OpenModeller, y los ensambla utilizando el módulo r.series
con la función median. Igualmente calcula el mapa de desviación están-
dar, aplicando la función stddev. La función v.random se utiliza para
generar dos conjuntos de puntos aleatorios (uno a escala global y otro
local), con la idea es muestrear más intensamente el ámbito local que el
global. Posteriormente extrae los valores de los puntos aleatorios y los
puntos de evaluación sobre los resultados de los algoritmos usando el
módulo v.what.rast y los exporta a tres tablas para la evaluación de los
modelos (VALORES ALEATORIOS GLOBAL.txt, VALORES ALEATO-
RIOS LOCAL.txt y VALORES PUNTOS EVALUACIÓN.txt). La orden
d.mon se utiliza para generar automáticamente mapas de los modelos y
el ensamblado a las escalas global y local, superponiéndoles los puntos
de calibrado y los puntos de evaluación. Estos mapas en formato png se
mueven a la carpeta RESULTADOS en el directorio de la especie.
◦ Evaluación de modelos: El actor EVALUA MODELOS lanza un script de
octave (8 EVALUA_MODELOS) que realiza los tests estadísticos
que calculan la precisión de los modelos.
◦ Composición de gráficos con los resultados: Los resultados de la eva-
luación, previo procesamiento, pasan al actor GRAFICOS, que lanza un
script de R (9 GRAFICOS EVALUACION) que genera una represen-
tación gráfica de los datos de evaluación, y el gráfico de distribución del
ensamblado en formato pdf. Este pdf se transforma en png mediante una
orden del programa ImageMagick y se copia a la carpeta RESULTADOS
en el directorio de la especie.
◦ Cálculo del umbral de corte del modelo. Para determinados cálculos pos-
teriores (por ejemplo, cálculo del área de presencia potencial de la espe-
cie) es necesario transformar un modelo continuo (valores de 0 a 100)
en modelo binario (0 y 1, indicando ausencia y presencia respectiva-
mente). Para esta transformación se selecciona en el modelo continuo,
según un criterio más o menos objetivo, un valor de idoneidad umbral
por encima del cual todas las celdas se recodifican con valor 1, mien-
tras que las celdas por debajo se recodifican con valor 0. Este umbral
representa el límite teórico entre hábitat óptimo y sub-óptimo. En este
caso el criterio lo determina el usuario a través del parámetro PORCEN-
TAJE_OMISION. Este valor indica el porcentaje máximo de puntos de
evaluación que pueden quedar excluidos del área de presencia del modelo
binario. Se interpreta como la proporción de localidades de presencia que
el usuario considera que se encuentran fuera de las condiciones apropia-
das para la especie. Un valor típico sería 5, indicando que el 95 % de las
poblaciones conocidas de la especie se encuentran dentro de su óptimo
ecológico. Un valor conservador puede ser 0, con el que se asume que
todas las poblaciones están dentro del óptimo. El valor del parámetro se

17
 pasa a un actor R (CALCULA_UMBRAL) que, utilizando la tabla con
los valores sobre el ensamblado de los puntos de evaluación, calcula el
cuantil correspondiente y lo exporta a un fichero de texto plano.
Como resumen final, listo las entradas y salidas esta sección del flujo:

ENTRADAS:

• Listado con especies que superan el criterio MIN_PRES.

• Ficheros formateados con las coordenadas de presencia.
• Variables ambientales de calibrado.

SALIDAS:

• Resultados de los ocho algoritmos de modelado.

• Mediana de la idoneidad del hábitat y desviación estándar.
• Análisis gráfico de distribución de valores de los ensamblados.
• Análisis gráfico de los resultados de la evaluación de modelos.
• Mapas de los resultados de los algoritmos, los ensamblados y dos mapas de
la distribución conocida de la especie.
• Ficheros de texto con todos los datos numéricos expresados en los gráficos.

18
 Recalibrado y proyección sobre
los distintos escenarios

En esta sección el flujo de trabajo vuelve a calibrar los modelos de distribución, pero
aprovechando en esta ocasión todos los puntos de presencia de la especie disponibles.
Los modelos numéricos resultantes (ficheros xml con las definiciones de los modelos en
OpenModeller y fichero de texto plano con los coeficientes de la ecuación en MaxEnt) se
utilizan para proyectarlos sobre las condiciones climáticas simuladas para el futuro. Cada
resultado se importa a GRASS para generar el ensamblado correspondiente. Durante esta
fase se muestrean los ensamblados con los puntos aleatorios y los puntos de presencia
para utilizar estos datos en la fase de análisis de los resultados. Este proceso se repite
para todos los intervalos de tiempo dentro de cada escenario.
Esta fase está dividida en dos secciones, recalibrado y proyección, ejecutadas por
sendos actores dentro del actor compuesto EJECUCION_MODELOS (ver Figura
12):
Recalibrado: El actor CALIBRADO_MODELO lanza la ejecución del script 11
inicia MODELOS CALIBRADO. Este script calibra los algoritmos con todos
los puntos de presencia, y guarda las definiciones de los modelos para su posterior
proyección. Una vez acabada la ejecución, lanza el batch-job de GRASS 12 ejecuta
MODELOS CALIBRADO, que ejecuta las siguientes tareas:

Figura 12: Actores que ejecutan el recalibrado y proyección de modelos. Ambos actores
se encuentran dentro del actor compuesto EJECUCION_MODELOS.

19
 • Genera el ensamblado (media y desviación estándar).
• Extrae los valores de los puntos aleatorios y de los puntos de presencia,
guardándolos en una tabla que se encargará de almacenar muestreos de todos
los modelos (los modelos recalibrados y los proyectados).
• Cálculo del área de ocupación potencial de la especie: Utilizando el valor
umbral calculado en la fase anterior por el actor CALCULA_UMBRAL, se
utiliza el módulo de GRASS r.recode y un fichero de texto (RECODE EN-
SAMBLADO CONTINUO) con las reglas para recodificar el ensamblado de
continuo a binario. A la superficie resultante se le aplica un filtro de moda
con un kernel de 3x3 celdas mediante el módulo r.neighbors para eliminar
celdas aisladas. Posteriormente se cuenta el número de celdas con valor 1 y
se exporta el resultado a un fichero de texto.
• Cálculo del número de parches de hábitat idóneo: La superficie binaria obte-
nida en el paso anterior se vectoriza (módulo de GRASS r.to.vect), y la tabla
del vector resultante, que tiene una entrada por cada polígono vectorizado,
se exporta a un fichero de texto. Este fichero tiene una columna llamada cat,
con un número identificador para cada polígono. Una orden de bash (tail)
lee la última línea del fichero de texto, y exporta el número cat a un nue-
vo fichero de texto. Este número es el total de parches de hábitat idóneo
correspondiente al ensamblado procesado.
• Exportación de imágenes png del ensamblado.

Proyección: El actor PROYECCION_MODELO lanza el script 13 inicia PRO-

YECCION. Este script utiliza las definiciones de los modelos para proyectarlos
sobre las nuevas condiciones. Está programado de forma que itera sobre la lista de
escenarios y periodos de tiempo, y actúa del siguiente modo en cada iteración:

• Proyecta las definiciones de los modelos sobre las variables del escenario
correspondiente a la iteración.
• Lanza el batch-job de GRASS 14 ejecuta PROYECCION. Este programa
hace con cada escenario exactamente las mismas tareas que el anterior (12
ejecuta MODELOS CALIBRADO).

Como resumen final, listo las entradas y salidas esta sección del flujo:

ENTRADAS:

Puntos de presencia de la especie.

Variables ambientales del presente y el futuro.

SALIDAS:

20
Archivos de los modelos numéricos de OpenModeller y MaxEnt.

Ensamblados de idoneidad y desviación estándar del presente y el futuro.

Mapas en formato png de los ensamblados.

Ficheros de texto con el número de celdas de hábitat idóneo en cada escenario.

Ficheros de texto con el número de parches de hábitat idóneo en cada escenario.

Tabla con los valores de idoneidad y desviación estándar de los puntos aleatorios
y de presencia.

21
Análisis y publicación de los
resultados

En esta fase final el flujo de trabajo analiza en detalle los resultados, teniendo en
cuenta varios puntos de vista: variaciones de la idoneidad del hábitat, migración altitudi-
nal, migración latitudinal, y evolución del área potencial y número de parches de hábitat
idóneo.
Con el objetivo es disponer, para cada especie, de un documento que contenga orga-
nizada toda la información relevante del proceso de modelado, preparé una plantilla html
sobre la que posteriormente el flujo de trabajo insertará automáticamente los distintos
elementos resultantes del análisis.

Análisis de los resultados

La primera fase de análisis se realiza en GRASS. El actor ANALISIS (ver Figura 13)
lanza la ejecución del script de bash 15 inicia ANALISIS FINALES. Este borra una
serie de ficheros temporales que ya no son útiles, y lanza el batch-job de GRASS 16
ejecuta ANALISIS FINALES. El script se encarga de:
Exportar y formatear datos que serán procesados en R (valores de los puntos
aleatorios para todos los ensamblados).
Comparar el modelo de evaluación con el modelo recalibrado mediante una resta,
para comprobar la distribución espacial de los cambios en idoneidad que supone
recalibrar el modelo con todos los puntos de presencia disponibles.
Generar un mapa de persistencia: el script suma todos los modelos binarios que
se han ido generando (para extraer número de celdas y número de parches de
hábitat idóneo) a partir de los ensamblados y transforma el resultado en un valor
de porcentaje. Este mapa de persistencia indica las áreas en las que, durante más
tiempo, se van a conservar condiciones apropiadas para la biología de la especie.
Exportar el mapa de comparación y el mapa de persistencia a formato png.
Llegados a este punto, para realizar el análisis, el flujo de trabajo ha entregado los
siguientes datos:

22
 Tabla VALORES_PUNTOS.txt. Se ha exportado del fichero vectorial que contiene
los puntos de presencia de la especie, los puntos aleatorios del ámbito global y los
puntos aleatorios del ámbito local. La tabla contiene, entre otros, los siguientes
grupos de campos:

• Valores de idoneidad de los algoritmos de las fases de evaluación y recalibrado.

• Valores de idoneidad y desviación estándar de los ensamblados de las fases
de evaluación, recalibrado y proyección (un campo de idoneidad y otro de
desviación estándar por cada escenario).
• Valores de las variables ambientales utilizadas para calibrar los modelos.

Fichero UMBRAL_CORTE_ENSCON.txt, con el valor apropiado para transfor-

mar el modelo continuo en binario.

Cuatro ficheros AREA_EC_(nombre escenario).txt, con el número de celdas de

hábitat idóneo correspondientes a cada escenario.

Cuatro ficheros PARCHES_EC_(nombre_escenario).txt, con el número de par-

ches de hábitat idóneo para cada escenario.

Estos ficheros son procesados por el actor GRAFICOS de la siguiente sección del flujo (ver
Figura 13). Este actor lanza un script de R (17 GRAFICOS ANALISIS FINALES)
que lee los datos, los organiza, y genera las gráficas descriptivas correspondientes, que se
discutirán en la sección de resultados. Cada salida gráfica de R es un fichero pdf con el
gráfico en cuestión, que se mueve al directorio de resultados de la especie, se transforma
en png mediante una orden de ImageMagick para el informe final, y se guarda el pdf,
para mantener una copia del gráfico en su versión de alta calidad.

Informe de resultados
Para hacer accesible la información resultante del flujo, se ha optado por un docu-
mento con una estructura basada en html, de forma que los resultados puedan colgarse
en un servidor web sin el menor esfuerzo.
La estructura diseñada consta de un primer documento denominado INICIO.html. Es
la portada principal de sitio, y posee un índice que da acceso a los resultados de cada
especie. El segundo documento, denominado PLANTILLA.html, es el informe sobre el
que se insertan los resultados (mapas y gráficos). Presenta una estructura secuencial
sencilla, y la única particularidad la suponen las animaciones.
Presentar series temporales de modelos de distribución como imágenes estáticas ocu-
pa mucho espacio y no resulta demasiado informativo, por lo que se ha seleccionado una
aplicación especialmente diseñada por Barry Rowlingson (Universidad de Lancaster), en
javascript, para generar animaciones interactivas en sitios web. Esta pequeña aplicación

23
Figura 13: Sección del flujo que se encarga del análisis de datos. Consta de dos actores
que ejecutan scripts (ANALISIS y GRAFICOS2), y una serie de ramas que procesan los
pdf resultantes de R para transformarlos en png y guardarlos en los directorios corres-
pondientes.

24
 Figura 14: Sección del flujo que formatea el informe html.

permite mostrar en el informe las series temporales de idoneidad del hábitat y desviación
estándar como animaciones con un control de velocidad, que mejoran la experiencia del
usuario en la consulta de los datos.
El flujo de trabajo tiene una pequeña sección dedicada a dar formato al informe (ver
Figura 14). Esta sección consta del actor PREPARA INFORME, que lanza el script de
bash 18 ORGANIZA INFORME. Este script mueve el archivo PLANTILLA.html al
directorio INFORME y lo renombra con el nombre de la especie. También mueve los
gráficos y mapas de la especie al mismo directorio, crea vistas previas reducidas usando
una orden de ImageMagick y prepara los directorios de las animaciones, renombrando
y moviendo los mapas de los ensamblados. El resto de la sección del flujo termina de
formatear el fichero insertando el nombre y la ficha de la especie (un fichero de texto
plano sobre la biología de la especie que el usuario debe situar en un directorio concreto
después de ejecutar el flujo preparatorio PRP).

25
LOS OTROS RESULTADOS DEL
FLUJO DE TRABAJO

En el capítulo correspondiente de la tesis ya trato los resultados que expone el informe

html. En esta sección trataré los otros resultados que ofrece MODPLAN, y que serán
útiles cuando sea necesario un análisis más exhaustivo de una especie: la base de datos de
GRASS resultante del proceso y las tablas de datos utilizadas para los análisis gráficos,
entre otros.

La base de datos de GRASS

Durante todo el proceso ejecutado por el flujo de trabajo, GRASS, además de realizar
operaciones, va almacenando todos los resultados importantes (los intermedios se han
ido eliminando sobre la marcha). Como consecuencia, al finalizar la ejecución se dispone
de un banco de datos muy valioso para otros análisis más concretos, como podría ser
el trabajo sobre una población determinada de una de las especies modeladas. Esta
información ocupará un gran volumen en el disco duro (varios cientos de Gigabytes
al trabajar a alta resolución con alto número de especies), y no está pensada para
ser difundida, sino para ser explotada por el propio operador del flujo de trabajo. Los
resultados se almacenan por motivos de organización en dos mapsets: EVALUACION y
PROYECCION.
En el mapset EVALUACION se almacenan las siguientes capas para cada especie:

Nombre_especie_CELDAS (raster): Las celdas del territorio con poblaciones co-

nocidas de la especie. Es el mapa de presencia de la misma a la resolución de
trabajo.

Nombre_especie_iniciales_algoritmo (raster): Siendo las iniciales: CH, EU, GA,

ME, MH, MN, NN, VM. Son los resultados de cada uno de los 8 algoritmos de
modelado.

Nombre_especie_EC (raster): Mediana de la idoneidad del hábitat. nombre_especie_DE

(raster): Desviación estándar de la idoneidad del hábitat.

26
 Nombre_especie_PRESENCIA (vector, tipo polígono o punto): Corresponde con
el shapefile original de la especie.

Nombre_especie_AMBITO (vector, tipo polígono): Mínimo rectángulo (más 2000

metros de margen) que acoge todas las poblaciones conocidas de la especie.

Nombre_especie_CALIBRADO (vector, tipo punto): Puntos de calibrado.

nombre_especie_EVALUACION (vector, tipo punto): Puntos de evaluación.

En el mapset PROYECCION se almacena el siguiente material:
Nombre_especie_EC_2000 (raster): Media de idoneidad para el mismo periodo.

Nombre_especie_DE_2000 (raster): Desviación estándar de la idoneidad del há-

bitat correspondiente al periodo de calibrado.

Nombre_especie_EC_escenario_periodo (raster): Media de idoneidad de una

proyección.

Nombre_especie_DE_escenario_periodo (raster): Desviación estándar de la ido-

neidad de una proyección.

Nombre_especie_PERSISTENCIA (raster): Mapa de persistencia de la especie,

resultante de la suma de todas las proyecciones transformadas en modelos binarios.

Nombre_especie_DIFERENCIAS_EC (raster): Mapa de diferencias en idoneidad

entre Nombre_especie_EC_2000 y Nombre_especie_EC.

Nombre_especie_VALORES_PUNTOS (vector, tipo punto): Contiene los puntos

aleatorios de los ámbitos global y local, y los puntos de presencia de calibrado y
evaluación. Para cada punto tiene campos que recogen los valores de idoneidad y
desviación estándar de todos los modelos, y los valores de las variables ambientales.
En el directorio RESULTADOS, en una carpeta con el nombre de la especie, se almacenan
los resultados que va generando el flujo. A continuación se detalla la estructura de
carpetas de una especie.
carpeta CALIBRADO. Contiene resultados relacionados con el modelo recalibrado.
Todos son gráficos generados por R en el actor GRAFICOS de la última sección
del flujo.

• ANALISIS_MODELO.pdf
• DIFERENCIAS_CALIBRADO_2_pdf
• DIFERENCIAS_CALIBRADO_EVALUACION_1.pdf
• REQUERIMIENTOS_ECOLOGICOS.pdf

27
carpeta EVALUACION

• HISTOGRAMA_EC.txt: valores del histograma del modelo inicial de idonei-

dad.
• PUNTOS_CALIBRADO_nombre_especie.txt: coordenadas de los puntos
de calibrado devueltas por el flujo de trabajo PRP.
• PUNTOS_EVALUACION_nombre_especie.txt: coordenadas de los puntos
de evaluación devueltas por el flujo de trabajo PRP.
• UMBRAL_CORTE_ENSCON.txt: Valor del umbral de corte del ensamblado
de idoneidad.

carpeta MODELOS: definiciones de los modelos de evaluación de OpenModeller y

MaxEnt.
carpeta RESULTADOS

• AUC_GLOBAL_VALORES.txt: valores de evaluación en el ámbito global

devueltos por actor EVALUA_MODELOS.
• AUC_LOCAL_VALORES.txt: valores de evaluación en el ámbito local.
• HISTOGRAMAS.pdf: gráfico de R con la distribución de valores del ensam-
blado de idoneidad de evaluación en el ámbito local.
• GRAFICOS_EVALUACION.pdf: gráfico de R que resume los valores de eva-
luación.

carpeta PRESENCIA

• CALIBRADO_nombre_especie.csv: puntos de calibrado formateados para

MaxEnt.
• CALIBRADO_nombre_especie.txt: puntos de calibrado formateados para
OpenModeller.
• PRESENCIAS_nombre_especie.csv: puntos de presencia completos para Ma-
xEnt.
• PRESENCIAS_nombre_especie.txt: puntos de presencia completos forma-
teados para OpenModeller.

carpeta MODELOS: definiciones de los modelos recalibrados de MaxEnt y Open-

Modeller.
carpeta PROYECCION

• ANALISIS_ENSAMBLADO_CONTINUO.pdf: gráfico de R que resume el

comportamiento de los modelos en las localidades de presencia de la especie.

28
 • ANALISIS_FUTURO_ESPECIE.pdf: gráfico de R que muestra el compor-
tamiento potencial de la especie ante los distintos escenarios.

carpeta RESULTADOS: contiene todas las imágenes que van al informe html, por
lo que se comentan a continuación.

29
Actores de Kepler utilizados

Kepler tiene un gran número de actores en su biblioteca de componentes, y en este

proyecto realmente se ha utilizado una pequeña proporción de ellos. En la Figura 15 se
muestran los actores de Kepler más utilizados en el flujo de trabajo y se esbozan sus
funciones.

File Reader: Lee un fichero de texto accediendo a él a través de una ruta local o
una URL (puerto fileOrURL), con lo que el contenido del fichero pasa al flujo de
trabajo a través del puerto output.

Text File Writer: Lee un flujo de texto entrante (puerto string), lo escribe en la
ruta indicada a través de fileToWrite, y emite la ruta del fichero escrito (puerto
fileWritten).

String Replace: Reemplaza una cadena (pattern) por otra (replacement) en

un flujo de texto (stringToEdit), emitiendo la cadena con el texto reemplazado
(output).

Display: Muestra en una ventana la información que le llega a través de input.

Repeat: Lee y repite un paquete un número determinado de veces predeterminado

por el usuario. Similar a un loop en un lenguaje de programación convencional.

Composite actor: Diseñado para contener flujos de trabajo completos. Array

Accumulator: Recibe elementos aislados y los devuelve como una cadena.

Array Sort: Ordena un listado de elementos según un criterio predeterminado por

el usuario. Expression To Token: Recibe como entrada una expresión (e.j. 2+2) y
devuelve el resultado.

Comparator: Lee dos valores (left y right), y los compara entre sí según el criterio
seleccionado por el usuario. Si el criterio se cumple emite un TRUE, y si no se
cumple, emite un FALSE. Ramp: Es equivalente a un bucle “for loop” de un lenguaje
de programación convencional. Genera valores en cada iteración según el valor de
paso step.

30
Boolean Switch: A través de control recibe un token booleano (TRUE o FALSE).
Dependiendo del valor recibido, envía el input por la salida correspondiente. Es un
actor de control de flujo utilizado para implementar ramificaciones condicionales
(equivalente a un “if”).

Directoriy Listing: Lee un directorio (directoryOrURL) e introduce en el flujo de

trabajo una lista de los elementos del directorio.

String Constant: Contiene una cadena de texto, generalmente una ruta, una
expresión o una orden, y la emite a través de output. Se utiliza, entre otras cosas,
para pasar órdenes al siguiente actor.

External Execution: Permite llamar a una aplicación externa o a un script.

Acepta un comando (command) y un directorio de trabajo para ejecutar su tarea.
Se utiliza para llamar los scripts de Bash, R, Octave y GRASS.

Expresión de R: Los actores R son muy flexibles, y pueden modificarse a voluntad

alterando el código y los puertos. El que se muestra lee una tabla, pero pueden
hacer casi cualquier cosa. Sin embargo, no ha sido posible utilizarlos para generar
los gráficos del flujo. Se ha mostrado más potente la posibilidad de invocar los
scripts de R mediante External Execution y la orden CMD BATCH.

Is Present: Comprueba la existencia de un fichero en el PC. Si el fichero está

presente emite un TRUE, y si está ausente un FALSE.

DDF Boolean Select: Recibe dos entradas (trueInput y falseInput) y un token

booleano de control. Emite la señal que corresponde con el token que recibe. Es
un actor difícil de manejar, con un comportamiento poco intuitivo, y que solo
funciona con el director DDF. Permite la ramificación condicional de un flujo de
trabajo.

31
Figura 15: Actores de Kepler utilizados en este proyecto.

32