Estudios de visibilidad en arqueología (III). Comparativa.

INTRODUCCIÓN:

Hola a todos, como lo prometido es deuda aquí tenéis el nuevo post, en el que haré una compartiva entre diferentes algoritmos de software libre que nos permite realizar cálculos de visibilidad.

Para ello vamos a usar dos programas SIG libres diferentes, por un lado GRASS y por otro SEXTANTE, en su plugin para gvSIG. En GRASS compararemos dos algoritmos r.los y r.viewshed. Por tanto al final tendremos tres comparaciones, dos en GRASS y otra en SEXTANTE, compararemos puntos como tiempos de ejecución, dificultad para llevarlos a cabo y otras cosas que al que escribe le llamen la atención. En principio vamos a usar la cartografía que ya hemos usado en otros post del área de Sagunto, de tal manera que poco a poco, con el devenir del tiempo, iremos conformando un pequeño estudio geográfico sobre el área en cuestión.

En cuanto a las problemáticas asociadas al estudio de visibilidad en arqueología, en principio no se van a tener en consideración, por tanto los resultados se basarán exclusivamente en lo que aporten los algoritmos de por sí, solamente teniendo en cuenta el vacío topográfico.

Las características básicas de hardware y software se detallan a continuación:

  • Sistema Operativo: Ubuntu 12.04 (precise) de 32-bit.
  • Núcleo: Linux 3.2.0-39-generic-pae
  • Procesador: Intel Core 2 Duo CPU E8400@3.00GHz x 2
  • RAM: 3,9 GiB
  • GRASS GIS 6.4.2 (el algoritmo r.los viene por defecto, mientras que para r.viewshed ha sido necesaria su instalación como plugin, puesto que no viene por defecto en GRASS 6.4.2).
  • SEXTANTE 1.0 sobre gvSIG 1.12.

Los parámetros que han de ser comunes a todos ellos son los siguientes:

  • Coordenadas del observador:  733664, 4395348.1 (se han elegido estas coordenadas al ser uno de los puntos de mayor elevación del acrópolis de Sagunto, según el MDE proporcionado por el CNIG en su web)
  • Altura del observador:  1’60 m. (Dado que de momento no se va a hacer un estudio pormenorizado del acrópolis saguntino,   vamos a considerar la altura de una persona. Actuaremos como si no hubieran torres de vigilancia, murallas o cualquier construcción que podría haber ayudado en esta tarea).

CREACIÓN DE UNA MÁSCARA:

Para reducir un poco el tiempo de procesamiento, vamos a reducir el área de estudio a las dos primeras zonas que consideré en la creación de capas de desplazamiento en un post anterior sobre la misma zona.

Para empezar lo que vamos a hacer es extraer las zonas que nos interesan, para que actúen como delimitador del área en cuestión. Para ello vamos a extraer de la capa vectorial esas dos zonas con la orden v.extract:

  • v.extract -d input=Costes_Reclass@Mapas output=area_2 where=value=2 or value=1

Luego, para poder usar dicha capa como máscara primero deberemos de rasterizar esta nueva capa resultante que hemos obtenido, para ello usaremos la orden:

  • v.to.rast input=area_2@Mapas output=area2_raster use=val

Ahora, si queremos que esta capa raster nos delimite un área deberemos usarla como máscara. Para ello ejecutaremos lo siguiente:

  • r.mask input=area2_raster@Mapas 

mascara

Como podéis ver, ya tenemos la máscara creada y aplicada sobre el mapa de elevaciones que vamos a usar para nuestra pequeña comparativa.

ANÁLISIS DE VISIBILIDAD:

GRASS: r.los

En primer lugar vamos a tomar como referencia el algoritmo r.los ya que es el que viene por defecto en GRASS:

  • r.los input=MDE-Sgt@Mapas output=vis_los coordinate=733664,4395348.1 obs_elev=1.60

Bueno, pues este algoritmo planteado así tal cual presenta algún que otro inconveniente, y es la lentitud del tiempo de ejecución. Para saber qué es lo que está pasando echamos un ojo a la documentación existente y encontramos que con respecto a r.los, nos dice lo siguiente:

The time to complete the calculation increases dramatically with the region size. Try to keep the columns and rows under 1000. (El tiempo para completar el cálculo se incrementa dramáticamente con el tamaño de la región. Intenta mantener las columnas y las filas por debajo de 1000).

Para conocer el tamaño de nuestro raster ejecutamos el comando r.info y ahí nos damos cuenta de que nuestro raster tiene 7.721 filas y 6.081 columnas, bastante más de lo que se recomienda en la documentación. Por tanto, si queremos ejecutar dicho comando en un tiempo razonable tendremos que reducir considerablemente el ámbito de acción de nuestro análisis.

rinfo

Por el comando r.info, sabemos que nuestro raster tiene una resolución de 5m por celda. Luego, mil columnas y mil filas, nos darían un total de 5.000 metros. Nuestro análisis debería estar por debajo de los 5 km, para que se ejecutase apropiadamente. Por tanto, teniendo este handicap en cuenta, lo que haré será limitar el análisis para un radio de 2.500 metros:

  • r.los input=MDE-Sgt@Mapas output=vis_los coordinate=733664, 4395348.1  obs_elev=1.60 max_dist=2500

Ahora si, en 252 segundos, se ha ejecutado el algoritmo produciendo un raster como salida. Sin embargo el alcance es mucho más reducido de lo que se había planteado en un principio. El resultado, sin embargo, se nos presenta no como un raster binario (1 = visible; 0 = no visible), si no como un raster con muchos datos, de acuerdo a con la documentación los datos son los grados desde los que es visible dicha celda desde el punto de observación. Si el valor es 0 se halla directamente debajo del punto de observación, si es 90 es que se halla horizontal y 180 si está por encima del observador. El ángulo de la celda que contiene el punto de observación está definido y ajustado a 180.

Si quisiéramos un mapa binario sería tan sencillo como reclasificar este mapa.

vlos

Como podemos comprobar la zona analizada es muy inferior a lo que pretendía en un principio.

GRASS: r.viewshed

Con este algoritmo los estudios de visibilidad son bastante más llevaderos, no se ha quejado en ningún momento de la extensión, y ha realizado todos los cálculos de manera rapidísima (356 seg concretamente), ya que el propio comando me daba la oportunidad de configurar la cantidad de memoria RAM que podía usar para el análisis, la he puesto en 1000MB. También me ha dado la oportunidad de obtener un mapa binario directamente, sin tener que recurrir luego al algoritmo de reclasificación. Los resultados podéis verlos vosotros mismos:

  • r.viewshed -b input=MDE-Sgt output=vis_viewsh coordinate=733664,4395348.1 obs_elev=1.60 memory=1000

visview

Este algoritmo no sólo nos deja las opciones que ya hemos visto, si no que permite configurar otros aspectos tales como la elevación del objetivo, un radio de visibilidad, considerar la curvatura de la tierra, así como un coeficiente de refracción, el cual no está explicado en la documentación. Hay que tener en cuenta que este algoritmo necesita de archivos temporales con los que trabajar, por ello hay un parámetro configurable que nos permite almacenar dichos ficheros, para luego poder borrar a mano tranquilamente.

Como podemos comprobar este algoritmo es muy completo y rápido, y mejora ostensiblemente el anterior r.los.

SEXTANTE-gvSIG:

La experiencia con esta combinación no ha sido muy satisfactoria, cierto es que la colaboración entre SEXTANTE y gvSIG no pasa por sus mejores momentos, sin embargo, la versión de la comunidad de gvSIG (gvSIG-CE) me arroja los mismos resultados. Parece que hay problemas con gvSIG y SEXTANTE. Aquí os dejo una muestra del resultado:

gvsig

Como podéis comprobar desgraciadamente los resultados no son los esperados. Por otro lado si os fijáis veréis que el radio es igual que el de r.los, esto se debe a que de igual manera los cálculos de este algoritmo se eternizan con el área elegida, por tanto me vi obligado a reducir considerablemente el radio de análisis. Por otro lado, debo reseñar que las tablas de color de gvSIG no están funcionando correctamente, ya que con las órdenes que le di, el aspecto debería ser otro, mucho más parecido a como lo vemos en GRASS.

He estado buscando otros algoritmos que calculen cuencas visuales, y algo he encontrado en SAGA, sin embargo, no me ha convencido ni los resultados, ni la forma de llevarlos a cabo, ya que no parece que acepte coordenadas de un punto de observación. Por otro lado, no he encontrado una documentación adecuada al respecto, por tanto he decidido no incluirlo en esta comparativa, ya que no podía comparar con los mismos parámetros.

CONCLUSIÓN:

Como conclusión de esta comparativa debo resaltar la potencia y el buen hacer del algortimo de GRASS r.viewshed, el cual ha realizado las tareas que se le ha pedido sin problema alguno y de manera muy eficaz. Resaltar que los otros dos algoritmos, r.los y el de SEXTANTE, son convenientes para zonas de reducido tamaño, (ya vimos que r.los necesitaba menos de 1000 columnas y filas para su correcta ejecución). Por tanto, si alguien me preguntara cual sería el algoritmo libre más conveniente para la creación de cuencas visuales, le recomendaría sin lugar a dudas r.viewshed de GRASS.

Espero que os haya resultado interesante este post. Ya sabéis, si es así, compartid. Gracias.

Deja un comentario