Más adelante, cuando tenga tiempo, colgaré una librería que he desarrollado en mi tesis y explicaré en detalle el código.

Hasta pronto.

Espero que os guste. Cuando tenga un rato subo más!!

Test de rendimiento SIMD con Mono.Simd.Vector8s

Las técnicas de computación paralela encuentran en los sistemas de información geográfica una de sus aplicaciones más elocuentes dada la naturaleza masiva de los datos geográficos, en particular si hablamos de estructuras de datos raster. No en vano, allá por el año 1997, Richard Healey, junto con otros compañeros del Dpto. de Geografía de la Universidad de Edimburgo, editó “Parallel Processing Algorithms For GIS”. El profesor Healey es un geógrafo que ya a principios de los 90 planteaba a sus alumnos problemas de geoprocesamiento paralelo que éstos habían de resolver con ADA, el único lenguaje accesible que por aquel entonces prefiguraba el paradigma OOP y permitía definir tareas concurrentes. Desde entonces se han producido muchos avances en paralelización de procesos, tanto a nivel de software como de hardware. Sin embargo, existe un tipo de paralelización que no parece haber alcanzado demasiada notoriedad en el campo de los GIS: se trata del conjunto de instrucciones SIMD (Single Instruction, Multiple Data) que permite realizar operaciones aritméticas entre pares de vectores mediante una sola instrucción. No se trata por tanto de concurrencia de procesos, sino de paralelismo a nivel de datos. Lo más curioso es que, desde 1996, los fabricantes de microprocesadores han ido incorporando extensiones que soportan en mayor o menor medida este juego de instrucciones.

Cualquier PC o videoconsola actual permite ejecutar instrucciones SIMD. Evidentemente los desarrolladores de juegos hace tiempo que explotan este tipo de paralelización. Sin embargo, encontrar referencias recientes a SIMD en el ámbito de la Geomática resulta más complicado: aquí tenéis una interesante ponencia de la conferencia de usuarios de GRASS del 2004. Seguramente habrá más trabajos publicados, así que hacednos saber lo que encontréis.

Yo sinceramente no sabía nada de esto hasta que leí este post de Miguel de Icaza, anunciando la publicación de Mono.Simd. Este API es un paso en la estrategia de Mono por entrar de lleno en la industria del “gaming”. ¿Y para las desarrolladores de GIS? En mi opinión significa un abanico de posibilidades a la hora de paralelizar geoprocesos que queda pendiente de explorar.

En este artículo sólo quiero dejar constancia de un test para un caso extremo de optimización con SIMD. En la práctica carece de utilidad, mi única intención es medir diferencias de tiempo en un escenario absolutamente favorable a la paralelización mediante vectores. Dado un grid de elevaciones, donde cada valor de altitud puede representarse como un entero de 16 bits, se trata simplemente de doblar el valor de cada pixel para “exagerar” el modelo del terreno. Estas son las especificaciones de la máquina en que he realizado el test:

• Intel Q8300 @ 2.50GHz
• 3.9 GiB RAM
• Ubuntu 11.04 i686
• Mono 2.10.5

El test se ha realizado sobre 4 ficheros ARC/INFO ASCII GRID de distintos tamaños. Para cada fichero se han tomado 5 muestras del tiempo transcurrido en el cálculo aritmético sin aceleración de hardware, pixel a pixel, tomando finalmente la mediana. La misma metodología de muestreo se ha empleado para obtener los tiempos con aceleración de hardware, es decir, empleando Mono.Simd para multiplicar los pixels de 8 en 8 mediante una única instrucción. Para ello es necesario agrupar previamente los valores de altitud y almacenar cada vector en una lista de tipo Mono.Simd.Vector8s. Estos son los resultados:

Como veis, en todos los casos, con SIMD el proceso de cálculo se completa en torno a 3,5 veces más rápido. Esto es una buena noticia, pero no significa que este tipo de paralelismo sea la panacea. En mi opinión la conclusión es que, si con un escenario favorable se puede reducir el tiempo de proceso en más de un 70%, merece la pena explorar otros escenarios con verdadera utilidad práctica.

Si alguien se pregunta por la incidencia que puede tener esta mejora en el rendimiento si contabilizamos el proceso de lectura y carga en memoria de los datos, me atrevería a decir que escasa. En cualquier caso, los procesos de lectura y manejo de grandes volúmenes de información raster constituyen un problema distinto y existen diversas técnicas para su optimización.

Si os pica la curiosidad, podeis averiguar el conjunto de instrucciones SIMD que soporta vuestro procesador ejecutando el código de ejemplo que aparece en la documentación de la clase Mono.Simd.SimdRuntime (es posible que tengáis que hacer algunas modificaciones). Para aquellos que quieran reproducir un test de rendimiento con sus propios ficheros ASCII GRID, aquí os dejo el código C# que he usado (por cierto, ni es óptimo ni puedo garantizar que esté libre de bugs):

using System;
using System.IO;
using Mono.Simd;
using System.Collections.Generic;
using System.Globalization;
using System.Diagnostics;
using System.Linq;

namespace SIMDTest
{
 class MainClass
 {
  public static void Main (string[] args)
  {
   bool useSIMD = true;
   string path = string.Empty;
   CultureInfo formatProvider = null;
   try {
    if (args.Length == 0) {
     Console.WriteLine ("Usage: SIMDTest [ASC GRID file name] [specific culture name]");
     return;
    }
    if (args.Length > 0)
     path = args[0];
    if (args.Length > 1)
     formatProvider = CultureInfo.GetCultureInfo (args[1]);
    Console.WriteLine ("Use hardware acceleration? [y / n]? : ");
    ConsoleKeyInfo key = Console.ReadKey ();
    while (key.Key != ConsoleKey.Y && key.Key != ConsoleKey.N) {
     Console.WriteLine ("Press 'y' to use hardware acceleration, 'n' otherwise: ");
     key = Console.ReadKey ();
    }
    Console.WriteLine ();
    Console.WriteLine ("Processing, please wait ...");
    useSIMD = (key.Key == ConsoleKey.Y);
    ElevationModel dem = new ElevationModel(path, formatProvider);
    Stopwatch stopwatch = new Stopwatch ();
    if (useSIMD) {
     Vector8s scale = new Vector8s (2);
     foreach (IList vPage in dem.EnumerateVectors ()) {
      stopwatch.Start ();
      for (int i = 0; i < vPage.Count; i ++)
       vPage[i] = vPage[i] * scale;
      stopwatch.Stop ();
     }
    } else {
     foreach (IList page in dem.EnumerateData ()) {
      stopwatch.Start ();
      for (int i = 0; i < page.Count; i ++)
       page[i] = (short) (page[i] * 2);
      stopwatch.Stop ();
     }
    }
    Console.WriteLine ("Time elapsed: {0}", stopwatch.Elapsed);
   } catch (Exception ex) {
    Console.WriteLine (ex.Message);
   }
  }
 }

 class ElevationModel
 {
  string _path;
  IFormatProvider _formatProvider = CultureInfo.CurrentCulture;
  short _noData = -9999;
  int BOD = 0;

  public ElevationModel (string path, IFormatProvider formatProvider)
  {
   if (string.IsNullOrEmpty (path))
    throw new ArgumentNullException ();
   else if (!File.Exists (path))
    throw new FileNotFoundException ();
   else {
    _path = path;
    if (formatProvider != null)
     _formatProvider = formatProvider;
    this.SetMetadata ();
   }
  }

  public ElevationModel (string path) : this(path, null)
  {
  }

  void SetMetadata ()
  {
   using (StreamReader reader = new StreamReader (_path)) {
    //skip GRID header
    for (int i = 0; i < 5; i++)
     reader.ReadLine ();
    _noData = short.Parse (reader.ReadLine ().Split (' ')[1], _formatProvider);
    reader.BaseStream.Position = 0;
    reader.DiscardBufferedData ();
    char[] buffer = new char[512];
    reader.Read(buffer, 0, buffer.Length);
    BOD = this.GetBeginOfData (buffer);
   }
  }

  int GetBeginOfData (char[] source)
  {
   int i = 0;
   bool isNewHeaderLine = false;
   bool isNewLine = true;
   foreach (char c in source) {
    if (char.IsLetter (c) && isNewLine) {
     isNewHeaderLine = true;
     isNewLine = false;
    } else if ((char.IsDigit (c) || c == '-') && isNewLine && !isNewHeaderLine) {
     break;
    } else if (char.IsControl (c)) {
     isNewLine = true;
     isNewHeaderLine = false;
    }
    i++;
   }
   return i;
  }

  IList<short> GetPage (char[] source, int sourceIndex, int sourceLength, IList pendingDigits)
  {
   IList<short> page = new List<short> ();
   for (int i = sourceIndex; i < sourceLength; i++) {
    if (char.IsDigit (source[i]) || source[i] == '-')
     pendingDigits.Add (source[i]);
    else if (pendingDigits.Count > 0 && (char.IsWhiteSpace (source[i]) || char.IsControl (source[i]))) {
     short n = _noData;
     string s = new string(pendingDigits.ToArray ());
     if (!short.TryParse(s, NumberStyles.Integer, _formatProvider, out n))
      Console.WriteLine ("Error parsing {0}", s);
     page.Add (n);
     pendingDigits.Clear ();
    }
   }
   return page;
  }

  public IEnumerable<IList<short>> EnumerateData ()
  {
   using (StreamReader reader = new StreamReader (_path)) {
    char[] buffer = new char[25000 * 1024];
    int beginOfData = 0;
    IList pendingDigits = new List ();
    int charCount = 0;
    while ((charCount = reader.Read (buffer, 0, buffer.Length)) > 0) {
     if (beginOfData == 0) {
      beginOfData = this.BOD;
      yield return this.GetPage (buffer, beginOfData, charCount, pendingDigits);
     } else
      yield return this.GetPage (buffer, 0, charCount, pendingDigits);
    }
   }
  }

  IList<Vector8s> GetVectorPage(IList page, IList pendingValues)
  {
   List vPage = new List ();
   foreach (short n in page) {
    pendingValues.Add (n);
    if (pendingValues.Count == 8 ) {
     vPage.Add (new Vector8s (pendingValues[0], pendingValues[1],
      pendingValues[2], pendingValues[3], pendingValues[4],
      pendingValues[5], pendingValues[6], pendingValues[7]));
     pendingValues.Clear ();
    }
   }
   return vPage;
  }

  public IEnumerable<IList<Vector8s>> EnumerateVectors ()
  {
   int lastPageSize = -1;
   IList pendingValues = new List ();
   foreach (IList page in this.EnumerateData ()) {
    IList vPage = this.GetVectorPage (page, pendingValues);
    // complete last vector in last page
    if (lastPageSize != -1 && vPage.Count < lastPageSize) {
     if (pendingValues.Count > 0 && pendingValues.Count < 8 ) {
      for (int i = pendingValues.Count; i < 8; i++)
	pendingValues.Add(_noData);
      vPage.Add (new Vector8s (pendingValues[0], pendingValues[1],
       pendingValues[2], pendingValues[3], pendingValues[4],
       pendingValues[5], pendingValues[6], pendingValues[7]));
     }
    }
    lastPageSize = vPage.Count;
    yield return vPage;
   }
  }
 }
}

En algunas ocasiones la solución a estos problemas sería “trocear” el raster y procesarlo por partes. Esto lo podríamos hacer con varios software y en todos ellos sería interesante poder automatizar la tarea al máximo.

1. Modelo digital raster

En este post propongo realizar una prueba con RSAGA, que es un modulo de R que permite acceder a las funciones disponibles en la consola de SAGA GIS. Para este post he trabajado en Windows, con R 2.10.1 y SAGA 2.0.4, aunque supongo que no habrá problemas con usar otras versiones más recientes. Además, deberéis instalar en R el paquete RSAGA.

2. Shapefile de polígonos con que trocearemos el raster

Para esta práctica podéis descargar dos ficheros (Imagenes 1 y 2), uno raster y otro vectorial (polígonos). A efectos didácticos se utilizan ficheros pequeños, pero esto resultaría más útil en caso de necesitar fragmentar más el raster. Por ejemplo, en artículos anteriores he presentado código para trabajar imágenes a nivel de parcelas agrícolas. En aquellos artículos trabajábamos las imágenes de una en una y ya estaban recortadas, pero las parcelas podrían ser miles y no queremos hacer eso a mano.

Conociendo SAGA GIS

Lo principal, como en tantos otros casos, sería conocer como se trocea un fichero raster con SAGA GIS. Para ello abrimos la GUI de SAGA y vamos a la pestaña “modules” que tiene forma de TOC, generalmente se encuentra a la izquierda de la ventana principal. En esta pestaña podemos encontrar las distintas librerías que agrupan módulos que se relacionan por algún motivo. Explorar estas librerías y practicar con ellas es el mejor modo de estar seguro de lo que se quiere hacer.

3. TOC de SAGA GIS donde podemos explorar las librerías y los módulos disponibles.

Finalmente, he decidido que lo mejor es empezar por separar el shapefile original por polígonos (shapes-tools/separate shapes) y después realizar un recorte por cada uno de los nuevos shapefiles (shapes-grid/clip grid with polygon). Practicar con el interfaz gráfico es un bueno modo de estar seguros de los parámetros que nos pide cada módulo.

Antes de empezar a usar RSAGA he tenido que averiguar los nombres exactos de los módulos y los parámetros que aceptan. Esto lo he hecho con los métodos rsaga.get.modules() y rsaga.get.usage(). Aunque generalmente se puede averiguar también viendo los nombres en el SAGA GUI o mirando en la carpeta donde se contienen las *.dll.

Trabajando con RSAGA

## Abrimos la consola de R y cargamos la librería
library(RSAGA)

## Seleccionamos el fichero raster que queremos trocear y una capa vectorial que queramos usar como límites. También especificamos el directorio donde van los outputs. Para trabajar con Windows recomiendo rutas sin espacios.
raster<- file.choose()
poligonos<- file.choose()
directorio <-choose.dir()

## Consultamos hasta encontrar la herramienta que nos separa un shapefile en varios, obteniendo un shapefile por cada polígono, o lo que quisiéramos. Por ejemplo:
## rsaga.get.modules("shapes_grid")
## rsaga.get.usage("shapes_tools", 7)
## Se ejecuta el método con los parámetros necesarios.
rsaga.geoprocessor(lib="shapes_tools", module=7, param=list(SHAPES=poligonos, PATH=directorio, NAMING=0, FIELD=6))

Una vez ejecutado este proceso ya disponemos de un shapefile por cada polígono, esto significa que aunque el shapefile original tuviera miles de registros solamente cargaremos en memoria uno a la vez. Esto ya supone un ahorro importante de recursos.

# Listamos los nuevos shapefiles
shapefiles <- list.files(directorio, full.names=T, pattern="\\.shp")
## Por último utilizamos RSAGA para realizar tantos recortes del raster como polígonos habíamos extraído
for(i in 1:length(shapefiles)){
select <- shapefiles[i]</code>
rsaga.geoprocessor(lib="shapes_grid", module=7, param=list(OUTPUT=select, INPUT=raster, POLYGONS=select))
}#fin bucle

Conclusiones

Tras ver este ejemplo nos queda más claro el uso de RSAGA y se visualiza bien como se podrían automatizar gran número de tareas habituales en los GIS. Intentar realizar estas tareas herramientas básicas y generales podría ser algo trabajoso.

En nuestro fichero de prácticas había 18 polígonos por lo que nuestro resultado es una carpeta donde encontramos guardados 18 shapefiles y 18 ficheros raster. Los recortes quedan como se puede ver en la siguiente imagen:

4. Uno de los 18 raster resultantes de los recortes y al fondo el shapefile original

En caso de ser necesario, se podría realizar más tareas sobre todos estos ficheros, con este software o con otros programas. Incluso se plantea la posibilidad de usar multithreading en R para ejecutar tareas con RSAGA. Proximamente haremos alguna demostración de esto.

Antes de acabar, solo quiero recordar quando trabajamos con RSAGA en Windows es posible que nos afecten algunas particularidades sobre el modo en que se forman las rutas (espacios, barras de directorios…) y los mensajes de error que aparecen no son de gran ayuda.

——————————————————————

Si queréis contactar podéis enviarme un email (asunto: gisandchips):

Benito M. Zaragozí

benito.zaragozi@ua.es

Figura 1: Parcelas estudiadas en este artículo.

Espero que este sea el primero de varios posts donde aprendamos a estudiar las ortoimagenes, extrayendo características de distintos tipos como ya hicimos en un post anterior (http://www.gisandchips.org/2009/11/11/procesamiento-de-imagenes-digitales-con-c-y-una-aplicacion-para-el-analisis-de-parcelas-agricolas/ ). En aquel caso, se extrajeron algunas sencillas frecuencias a partir del cálculo de la Transformada de Hough que nos proporcionaba AForge.NET, lo cual nos servía para automatizar la decisión de si una parcela era una plantación arbórea y realizar un conteo automático del número de árboles que contenía. En dicho post, se ofrece una aplicación llamada RAPID, que incorpora una galería de imágenes de parcelas agrícolas. Hemos extraído tres de ellas para realizar los siguientes análisis. Son las siguientes:

Al estudiar las 3 parcelas que aparecen en la Figura 1 con el RAPID: La primera es identificada totalmente como agrícola y nos permite contar con bastante certidumbre el número de árboles de un modo automático. En el caso de la segunda, su estructura en hileras no permite el conteo de árboles pues están muy juntos. Y por último, en los olivos de la tercera no se cumplía la regla de una estructura normal, aunque sí que podíamos contar los árboles. Este último caso era el único donde RAPID no podía “acertar” pues identificaba la parcela como no agrícola debido a que la diferencia angular entre las direcciones principales de la Transformada de Hough no se aproximaba a 90º.

¿Qué es un variograma experimental? (una breve explicación para entender los resultados)

Los variogramas se utilizan para caracterizar la posible estructura espacial de un conjunto de datos. Podemos distinguir dos tipos de variogramas, el experimental y el modelizado. De estos nos interesa más el experimental. Este último se usa para describir los datos de una muestra, habitualmente una nube de puntos (xyz)

Matemáticamente el semi-variograma, o variograma/2, se puede definir como la mitad del promedio de las diferencias al cuadrado.

Figura 2: Fórmula para calcular el semi-variograma

Donde Np(h) es el número de pares a la distancia h, h es el incremento.

Z(xi) son los valores experimentales.

xi localizaciones donde son medidos los valores z(xi).

Aplicado a imágenes, el semi-variograma (o variograma/2), mide el grado de correlación espacial entre los píxeles de una imagen. Podemos comentar varios conceptos (ver Figura 3):

• Sill o meseta: representa la varianza máxima.
• Range, rango o alcance: muestra la distancia (en nuestro caso en píxeles) a la que el semi-variograma alcanza la meseta.
• Nugget o “efecto pepita”, es la discontinuidad en el origen. Ésta es debida a que el semivariograma, en la práctica, no es nulo en el origen.

Figura 3: Interpretación del semivariograma

Ejemplos de cálculo en R

Os aviso de que las imágenes referidas en el código estan en formato *.ppm aunque R tiene muchas librerías capaces de convertir a este formato. También podéis utilizar OpenOffice.

En este post, aplicamos el siguiente código para calcular el semi-variograma empírico de cada una de estas imágenes:

<pre># Instalo los packages necesarios:

#-------------------------------------------------

install.packages("pixmap", dependencies= T)

install.packages("fields", dependencies= T)

# Cargo las librerias:
#-------------------------------------------------
library(pixmap)

library(fields)

# Hago una lista con las imagenes de las parcelas y las cargo todas:
#-------------------------------------------------
imag_dir <- list.files("C:\\ ... \\Articulos Gisandchips\\ parcelas_ppm\\", full.names=T)

parcela1 <- read.pnm(imag_dir[1])

parcela2 <- read.pnm(imag_dir[2])

parcela3 <- read.pnm(imag_dir[3])

# Aislamos una banda...
#-------------------------------------------------
matriz1<-parcela1@green

matriz2<-parcela2@green

matriz3<-parcela3@green

# Calculamos el semivariograma (si queremos podemos acabar antes cambiando el alcance de 40  a 10, por ejemplo, pero los resultados pueden cambiar y quedará menos bonito (-: )
#-------------------------------------------------
vgram1_40<-vgram.matrix( matriz1, R=40) # esto llevará un poco de tiempo

vgram2_40<-vgram.matrix( matriz2, R=40) # esto llevará un poco de tiempo

vgram3_40<-vgram.matrix( matriz3, R=40) # esto llevará un poco de tiempo

# Añadimos al Plot las matrices que acabamos de calcular
#-------------------------------------------------
plot.vgram.matrix(vgram1_40)# La matriz del variograma

plot.vgram.matrix(vgram2_40)# La matriz del variograma

plot.vgram.matrix(vgram3_40)# La matriz del variograma

# Creamos una curva que ajuste bien sobre la muestra y la añadimos al variograma
#-------------------------------------------------
polyfit1_40_20 <- lm(vgram1_40$vgram ~ poly(vgram1_40$d, 20));

plot(vgram1_40$d, vgram1_40$vgram)

lines(sort(vgram1_40$d), polyfit1_40_20$fit[order(vgram1_40$d)], col=2, lwd=4)

polyfit2_40_20 <- lm(vgram2_40$vgram ~ poly(vgram2_40$d, 20));

plot(vgram2_40$d, vgram2_40$vgram)

lines(sort(vgram2_40$d), polyfit2_40_20$fit[order(vgram2_40$d)], col=2, lwd=4)

polyfit3_40_20 <- lm(vgram3_40$vgram ~ poly(vgram3_40$d, 20));

plot(vgram3_40$d, vgram3_40$vgram)

lines(sort(vgram3_40$d), polyfit3_40_20$fit[order(vgram3_40$d)], col=2, lwd=4)

El plot que obtenemos es el siguiente, o similar si es que hemos preferido cambiar algún parámetro:

Figura 4: Panel donde mostramos los resultados

En la imagen vemos las parcelas, la matriz de su variograma y el variograma, con una curva que ajustamos mucho al los datos. Es fácil interpretar que en la estructura de las parcelas se llega a apreciar cierta “ciclicidad”, ya que encontramos mesetas a distintas distancias. Cada meseta se  corresponde aproximadamente a las hileras de árboles. El alcance es el que hemos definido (40, en este caso 40 píxeles; puede que unos 20 m. en la realidad).

Viendo estas imágenes nos podemos dar cuenta de que es más fácil determinar una regla de clasificación que cuando lo hacíamos en el caso del RAPID. En este caso, nos fijamos en el número de máximos relativos de la función polinómica de ajuste del variograma. A simple vista, la primera parcela tiene unos 4, la segunda apenas 1 y la última 3 o 4. En este caso, podríamos citar una nueva regla para nuestro programa según la que a partir de 2 o 3 máximos relativos una parcela puede ser considerada una plantación arbórea.

Como nos interesa automatizar la tarea creamos una función que nos cuente los máximos relativos. Aquí viene el ejemplo aplicado a la primera parcela:

# Encontrar máximos relativos en la función 1

#--------------------------------------------------

maxRelativos1=0

hMaxRelativos1=0

for(i in 1:(length(polyfit1_40_20$fitted.values)-1))

{

if (polyfit1_40_20$fitted.values[i] > polyfit1_40_20$fitted.values[i+1] && polyfit1_40_20$fitted.values[i] > polyfit1_40_20$fitted.values[i-1])

{maxRelativos1[i]<- polyfit1_40_20$fitted.values[i]

hMaxRelativos1[i]<- vgram1_40$d[i]}

}

MaxRelativos1<-data.frame(hMaxRelativos1,maxRelativos1)

MaxRelativos1<- na.omit(MaxRelativos1)

NumMaxRelat1_40<-length(rownames(MaxRelativos1))

Consultamos los vértices de la curva que hemos dibujado mediante un bucle, de modo que si el vértice i tiene un valor superior al vértice anterior y también al vértice posterior entonces es considerado un máximo relativo y queda almacenado en la lista.

Algunos comentarios sobre todo esto:

(1) El semivariograma implica un gran esfuerzo de cálculo por parte del ordenador. Esto hace que aún habiendo varias librerías en R que obtienen el semivariograma de una nube de puntos, sean significativamente más lentas que Fields. Además, Fields hace directamente lo que necesitábamos. No obstante, en un futuro no muy lejano, intentaré desarrollar una librería en C# para reproducir un análisis de este tipo y otras cosillas relacionadas.

(2) Por cuestiones de tiempo no he tratado de crear funciones para las distintas etapas de la demostración. Puede ser un buen ejercicio tratar de implementar todo esto en funciones que permitan entre sus parámetros especificar la banda con la que trabajar, el alcance del semivariograma…

(3) Existen más posibilidades a la hora de establecer reglas, por ejemplo podríamos explorar la distancia que separa los máximos relativos para distinguir los cultivos más intensivos de los más tradicionales. Se me ocurren muchas más posibilidades.

(4) Por último, aunque no le doy mucha importancia, deciros que el número de máximos relativos no es del todo correcto pues el cero siempre aparece en el conteo (sale 5, 2, 5 y no 4, 1, 4 como he dicho más arriba), esto es porqué no he trabajado bastante el bucle, pero es fácil restar 1 a la lista final.  Mi idea principal es la de explorar el concepto y dar unos ejemplos de código a modo de ideas.

Referencias:

Para entender bien todo esto creo que es interesante ver mi artículo anterior…

Solamente os remito al siguiente tutorial de Surfer. Es bastante didáctico. http://www.goldensoftware.com/variogramTutorial.pdf

De todos modos la red está llena de materiales, apuntes de clase, libros en PDF… No tendréis problemas en encontrar información sobre los variogramas.

——————————————————————-

Si quereis contactar podeis enviarme un email (asunto: gisandchips):

Benito M. Zaragozí

benito.zaragozi@ua.es

Imagen1

En primer lugar, Aforge.NET es un Framework con distintas librerías que abarcan un amplio rango de campos relacionados con el tratamiento digital de imágenes. Se trata de un proyecto GNU GPL disponible en http://code.google.com/p/aforge/ . Es un proyecto consolidado pero también muy prometedor, en el que Andrew Kirillov tiene un gran trabajo realizado.

Según vemos en la página Web entre sus librerías se encuentran:

• AForge.Imaging – library with image processing routines and filters;
• AForge.Vision – computer vision library;
• AForge.Neuro – neural networks computation library;
• AForge.Genetic – evolution programming library;
• AForge.Fuzzy – fuzzy computations library;
• AForge.MachineLearning – machine learning library;
• AForge.Robotics – library providing support of some robotics kits;
• AForge.Video – set of libraries for video processing
• etc…

Se me ocurre que alguien se podría plantear un AForge.GIS. Pensaremos en ello…

Nosotros hemos trabajado únicamente con Aforge.Imaging, pero salta a la vista la potencialidad que prácticamente todas las librerías tendrían para realizar análisis espaciales.

Introducción

Actualmente, al trabajar en cuestiones de teledetección aplicada a fotografías aéreas e imágenes de satélite se esta aplicando cada vez más el paradigma del Análisis Orientado a Objetos (AOO), pasando de hablar de los valores de los píxeles, a las propiedades de los objetos. Podríamos resumirlo como: teledetección orientada a objetos.

No voy a tratar de hablar de análisis orientado a objetos, pues considero que hay abundante información en Internet.

Solamente por sentar el ejemplo que vamos a trabajar en este artículo, “Objeto” sería una parcela agrícola que podría tener múltiples “propiedades” como un área, perímetro, otros índices de forma… pero también tendría propiedades basadas en la respuesta espectral de la superficie que encierra, por ejemplo los valores de un índice de vegetación. También serían propiedades muy descriptivas de la parcela aquellas que describan la estructura generada por la distribución de los píxeles. Así pues, para una sola parcela podríamos tener muchísimas propiedades que la describieran, claro está, siempre unas lo harían mejor que otras.

En AForge.Imaging están disponibles distintas funciones de análisis para la extracción de estas propiedades o características a partir de una imagen, como por ejemplo la Transformada de Fourier, distintos algoritmos de detección de bordes y la que nos interesa aquí: La Transformada de Hough.

En definitiva, hemos elaborado una aplicación de escritorio que calcula la transformada de Hough para la imagen aérea de una parcela, y después de aplicar unas sencillas reglas para decidir si se trata de una parcela agrícola y arbórea, permite contar automáticamente los árboles de dicha parcela.

La Transformada de Hough

Se trata de una técnica utilizada para extraer elementos, con una forma particular, a partir de una imagen. Es comúnmente aplicada para encontrar y describir líneas rectas en una imagen, aunque también se pueden hallar círculos y otras formas. En la carpeta de ejemplos de AForge podéis encontrar el ejemplo en el que me he basado, en el cual se aplica Hough para hallar líneas y círculos dentro de una imagen.

Aquí no vamos a explicar los fundamentos de cálculo, sino la interpretación que podemos hacer de los resultados en nuestro caso del análisis de parcelas.

En concreto uno de los datos que obtenemos aplicando Hough es la inclinación de cada una de todas las líneas rectas halladas, como también la intensidad de cada línea (en nuestro caso tendrán mayor intensidad las líneas que más árboles atraviesen).

Solamente viendo la imagen1 podríamos intuir cuales serían las inclinaciones/direcciones de las dos líneas de mayor intensidad halladas por Hough, pero como se ve en la imagen no hay una coincidencia exacta debido a pequeños detalles (los árboles no están homogéneamente separados, la parcela no es cuadrada…).

Nota: las líneas rojas no son las de mayor intensidad, solamente muestran las direcciones.

En la Imagen2 vemos como las direcciones principales son muy similares, y esto nos indica que difícilmente la parcela tendrá la estructura necesaria para realizar el conteo de árboles.

Imagen2

Reglas de decisión

Una vez calculado Hough usamos algunas estadísticas de las líneas halladas para crear reglas de decisión que ayuden a distinguir automáticamente la estructura de la parcela.

De un modo arbitrario a partir de las pocas parcelas vistas he decidido que serán agrícolas – arbóreas aquellas parcelas cumplan lo siguiente:

• aquellas parcelas que tengan una diferencia angular entre las dos direcciones principales comprendida entre 80 y 120,
• o que el % de líneas en la 1ª dirección no sea mucho mayor que el % de la 2ª (<2x)

Estas reglas deberían ser más complejas y basadas en algún clasificador estadístico o matemático. Pero para ser didáctico es más que suficiente.

Rough Agricultural Plots IDentifier (RAPID)

RAPID es el nombre que le hemos dado a nuestra aplicación de ejemplo. Es un identificador “basto” de parcelas agrícolas. No hay que esperar maravillas, pero veréis que acierta bastante.

Imagen3

La aplicación muestra una barra de tareas donde se secuencian los pasos de análisis y a medida que se realiza cada paso se activan nuevos botones.

Los botones son:

• OpenImage: permite añadir imágenes propias.
• Binarize: binariza la imagen aplicando el umbral especificado en el cuadro de texto.
• Calc Hough: calcula la transformada de Hough para la imagen binaria y muestra algunas estadísticas en es cuadro de la derecha. También muestra un mensaje sobre la adecuación, o no, de la parcela.
• Count Trees: realiza el recuento de árboles de la imagen binaria y muestra el resultado en el cuadro “Trees estimation”. Este último no debería activarse en caso de que no se cumplieran las condiciones establecidas en nuestras reglas, pero se activa para facilitar todo tipo de pruebas.

Por último, y para ahorrar tiempo se ha añadido una galería de imágenes de parcelas extraídas del visor del SIGPAC (http://sigpac.mapa.es/fega/visor/ ). He intentado que haya cierta variedad. Hay algunas parcelas donde resulta fácil el recuento (1, 2, 6, 8 ), pero también es muy interesante ver como se rechazan las otras parcelas. En algunos casos el conteo de árboles sería difícil incluso manualmente sobre la imagen.

En el caso de la parcela 8 de los ejemplos, vemos que RAPID hace un recuento bastante preciso de los olivos de la parcela 8 de los ejemplos (SIGPAC = 148; RAPID +/- 150, según el Threshold). Por supuesto que seríamos más precisos si elimináramos los ruidos que los bordes de la parcela introducen en el análisis.

Imagenes 4 y 5

Podéis ajustar el umbral, y veréis como el recuento mejora en algunas imágenes. Esto también se podría automatizar.

Otra cuestión es que hemos trabajado sobre una imagen RGB, pero es evidente que la distinción de los árboles mejoraría mucho si dispusiéramos de una banda de infrarrojo próximo y la combináramos con las otras antes de realizar la binarización.

Algunas cosas sobre el código

La mayor parte del código que he escrito se corresponde con aspectos del UI, lo que da una idea de cómo de bueno es AForge.

He organizado el código en un fórmulario y tres clases. Hay una clase para binarizar una imagen aplicando unos pocos filtros, otra para obtener las estadísticas de Hough y la última realiza el recuento de “blobs”, en este caso árboles.

Solamente me interesa destacar el uso de FilterSequence que permite predefinir el uso de varios filtros, lo cual resulta muy práctico.

// binarization filtering sequence

FiltersSequence filter = new FiltersSequence(

new ContrastCorrection(),

new Mean(),

new GrayscaleBT709(),

new Threshold()

);

Por otra parte, si usando filtros y otras herramientas notáis que hacen justo lo contrario de lo que deberían, es porque justamente están haciendo lo contrario . Deberéis aplicar un Invert() al Bitmap. Esto me pasaba con el BlobCounter(), pues me devolvía la cuenta de todo lo que no eran árboles. También deberéis invertir la imagen si queréis usar filtros del tipo Erosion() o Dilatation().

El codigo fuente lo podeis obtener haciendo un checkout del siguiente repositorio subversion: svn co http://www.gisandchips.org/svn/rapid/

Referencias

• De nuevo la página del proyecto: http://code.google.com/p/aforge/

• Para entender mejor esta técnica podéis consultar http://en.wikipedia.org/wiki/Hough_transform

• Antes del verano asistí a un curso en Valencia (Esp.) donde aprendí bastante de este tema. Como me gustó bastante os adjunto la referencia por si lo repiten de nuevo el año que viene: Teledetección aplicada a la actualización de cartografía de ocupación del suelo: técnicas de clasificación orientada a objetos. Curso teórico-práctico. http://cgat.webs.upv.es/bigfiles/c_objetos/index.html

——————————————————————-

Si quereis contactar podeis enviarme un email (asunto: gisandchips):

Benito M. Zaragozí

benito.zaragozi@ua.es

]]> http://www.gisandchips.org/2009/11/11/procesamiento-de-imagenes-digitales-con-c-y-una-aplicacion-para-el-analisis-de-parcelas-agricolas/feed/ 3 http://www.gisandchips.org/2009/11/09/informacion-geografica-turismo-ra-y-la-necesidad-de-estandares-abiertos/ http://www.gisandchips.org/2009/11/09/informacion-geografica-turismo-ra-y-la-necesidad-de-estandares-abiertos/#comments Mon, 09 Nov 2009 13:03:23 +0000 Novatores http://www.gisandchips.org/?p=452 Hace 16 años les decía a mis alumnos de Nuevas Tecnologías en Turismo que llegaría un momento en que la gente preferiría pasar el tiempo navegando por páginas WEB en Internet que viendo la televisión, aunque aquéllos me expresaban desconfianza (todos los profesores de este tipo de materias reconocemos esas miradas que nos delatan a los ojos del auditorio como “profetas iluminados” con una “visión”…). Un par de años después,  sentí lo mismo  impartiendo un curso a empresarios del sector, les aseguraba que casi todos los vehículos acabarían incorporando un navegador GPS de serie en el que se consultaría  información geográfica de los callejeros y de la ubicación de determinados servicios, para poder llegar a ellos con facilidad. ¡Todavía recuerdo la expresión de un grupo de ellos que  murmuraba con mueca incredula: “…¡con lo fácil que es bajar la ventanilla y preguntar…!”Edit

En los tres o cuatro últimos meses afloran referencias en los blogs y foros de Sistemas de Información Geográfica (SIG) sobre la tecnología Layar y Android. Pero mientras muchos nos dedicamos a saborear cómo se materializa la información geográfica en aplicaciones de Realidad Virtual, como la Realidad Aumentada, quizá valdría la pena pararse a considerar la magnitud que puede alcanzar el fenómeno, sus consecuencias e incluso, permitirnos el lujo de recoger opiniones y sugerencias inspiradas en otras experiencias anteriores de propagación de tecnologías de la Información y la Comunicación (TIC) muy cercanas todavía en el tiempo.

Partiendo de las ideas expuestas en el Blog de Joe Ludwuig acerca de este tema, me gustaría dedicar un tiempo a reflexionar sobre la expectativa de éxito de la realidad aumentada (RA) y los Sistemas de Información Geográfica (SIG), pues parece evidente que la mayor rentabilidad para un proveedor de plataforma de RA no será a corto plazo…, pero si algo hemos aprendido del estudio de cómo se ha desarrollado la WEB, es que pese a ello no erraríamos al vaticinar un extraordinario desarrollo de esta tecnología en un par de años.

Precisamente, la naturaleza abierta del WEB y su facilidad de uso permitieron en su momento que cualquiera se animará a participar, no hizo falta convencer a nadie, tampoco lo hubiera/n podido hacer una empresa o grupo de empresas en solitario, el éxito de la WEB, desde princios de los noventa fue la participación masiva a un bajo coste, con la posibilidad de que una buena idea pudiera convertirse en un fabuloso negocio. Es decir, una nueva forma de divulgar la información proporcionaba la estimulación de nuevas facetas de mercado y de relación (también comercial) entre los grupos humanos.

Si tomamos el ejemplo de desarrollo de la navegación WEB , debemos considerar que la RA tiene un extraordinario potencial, pero no debemos perder de vista que una de las claves del éxito en el desarrollo de la WEB fue la ausencia de barreras institucionales que obstaculizaran su vertiginoso ascenso; gracias ello, la WEB pudo crecer en la misma medida que crecía la RED DE USUARIOS y la RA haría muy bien en “tomar nota de esto”.

RA-“a”: Realidad Aumentada y “Abierta”

Si el nuevo ecosistema de la RA quiere crecer tan rápido como la WEB lo hizo, no puede depender de que una empresa, grupo de empresa o instituciones dicten el permiso o arbitren los protocolos encaminados a dejar que los usuarios existentes puedan obtener una nueva capacidad y ello impone que cualquiera pueda publicar contenido en el sistema y que por tanto, no haya “cuellos de botella” para ello, ni siquiera justificados en la calidad o pertinencia adecuada de los datos.

En el mundo de la información geográfica tenemos un buen ejemplo de ello en iniciativas exitosas como Google Maps u OpenStreetMap, incluso en otras opciones que parecían más modestas, como WikiLOC (reconocido con el Geoturism Challenge 2009 de Ashoka Changemaker y National Geographic). Todas ellas deben una buena parte de su éxito al uso de formatos normalizados y abiertos, sin exceso de trabas o controles institucionales, lo que conduce la generación de aplicaciones que piensan más en el usuario, sus capacidades y sus necesidades, generando iniciativas de carácter participativo y colaborativo muy capaces de enriquecer la cantidad y  utilidad de la información en la que se basan estos servicios.

La información debe estar accesible para múltiples clientes, desde distintos proveedores. Cualquiera debe ser capaz de crear un cliente que pueda trabajar con estos contenidos de información sin “grandes complicaciones”. Del otro lado, la solicitud de información de estos clientes debe poderse satisfacer por la respuesta de múltiples proveedores de contenido y de forma totalmente transparente al usuario final (recordemos la Teoría del Iceberg: gran cantidad y complejidad de recursos, pero puestos a disposición del usuario de forma muy simple, la facilidad de uso es inversamente proporcional a la infraestructura de información puesta en juego, sólo vemos una pequeña parte de lo que hay por debajo)

Tampoco debería ser un sistema basado en la rigidez de un directorio central de contenidos o de un directorio por cada uno de los proveedores de contenidos, pues al estilo de los servicios WEB del Open Geospatial Consortium (OGC), los contenidos deberán estar accesibles y adaptados de manera abierta a una normalización de los formatos que faciliten su uso (concepto de “usabilidad”).

Finalmente, la infraestructura tecnológica debe ser independiente de la información, de los datos que se transmiten por ella. Los proveedores de Internet Móvil, las empresas fabricantes de smartphones, etc, no deben controlar o ser parte especialmente implicada en el sector de los proveedores de información y de los desarrolladores de aplicaciones.

La “brecha digital” para esta tecnología se situará pivotada en dos puntos: disponibilidad de información o aplicaciones, por un lado,  y acceso a equipos de calidad apropiados para este tipo de tecnologías. No nos engañemos, los equipos de telefonía móvil compatibles son sofisticados y todavía de un precio elevado para muchos de los posibles usuarios de nuestro país (500-600 €)  y la ausencia de datos – aplicaciones disponibled no justifica todavía el alto grado de inversión económica requerido para el uso de la RA y la información geográfica por parte del consumidor medio.

En esta estadística sobre el país de procedencia de los usuarios de LayarSPAIN (empresa SIGNO Ingenieria del Territorio),  se pone claramente de manifiesto lo que queremos decir:

El uso de esta tecnología para la información turística de LayarSpain por usuarios españoles se limita al 6%, mientras que estadounidenses, holandeses y británicos representan el 40% de los usuarios.  Precisamente ahí es dónde el uso de estándares abiertos puede ayudar a hacer más pública la tecnología; en efecto, la facilidad para desarrollar aplicaciones y publicar contenidos  puede ser la  solución a este problema, pues a mayor cantidad y calidad de la información mayor número de usuarios dispuestos a “pagar por…” , a mayor cantidad de usuarios mayor abaratamientos de costes en dispositivos, mayor accesibilidad tecnológica, desarrollo de más innnovaciones y en definitiva, lo que podríamos entender como una sinergia favorable.

La clave del éxito: estándares abiertos

Las consideraciones anteriores no implican la necesidad de un papel protagonístico del software abierto como Linux, Apache, Perl, PHP, etc. Aunque este tipo de aplicaciones han sido cruciales en el desarrollo de Internet, ello no implica que el uso de la información geográfica en el desarrollo de la RA se tenga que limitar necesariamente a ellas.

Sin embargo, la normalización de los datos, el fácil manejo de la información mediante el uso de fórmulas sencillas, es algo que sí puede convertirse en la espina vertebral del proceso. En los últimos años tenemos ejemplos de cómo el desarrollo de una nueva normalización está lleno de peligros, sobre todo, por que el exceso de celo puede llevar a la “asfixia” del proceso, como en el caso del lenguaje de modelado de Realidad Virtual (VRML). Afortunadamente, para el uso de la información geográfica y la RA, hay normalización ya vigente que se presta muy bien a resolver los problemas que los desarrolladores de realidad aumentada pueden encontrar en este sentido (protocolos de intercambio de información, formatos de datos, servicios WEB,…).

La primera de ellas es el antiguo protocolo de transporte de hipertexto (HTTP) que se ajusta a las características de “usabilidad” que hemos comentado antes. Es un protocolo que se entiende bien, descentralizado y disponible en el servidor o en forma de biblioteca cliente para cada plataforma. Además, están surgiendo nuevos y eficaces estándares para la consulta de localización específica de datos.

Un formato normalizado que los desarrolladores de RA pueden adoptar es el  keyhole markup language (KML), de Google y que Google Earth utiliza para representar la información geocodificada. Tiene la ventaja de hacer uso de una gramática muy similar y casi compartida con el GML del OGC,  con un buen soporte para los objetos geográficos-geométricos. Es un estándar abierto y es soportado por muchos programas de SIG, además de que Google Maps y Google Earth han contribuido a su divulgación hasta el punto de hacerlo norma, con la garantía de haber divulgar la información geográfica como aplicaciones basadas en él, lo que significa un buen banco de pruebas).

De hecho, el 14 de abril de 2008 Google consiguió que el OGC estableciera el formato KML como un estándar abierto, lo que casi lo consagra como punto de partida. Todavía está caliente del horno el estandar ARML, como efecto derivado de lo anterior, evidencia la intensidad de lo que estamos apuntando. Aunque hay quien todavía afirma que es mucho más práctico el uso de otros protocolos o estándares como IRC o RSS, usando canales como capas de información que se pudieran activar o desactivar, compartir o no a voluntad.

En definitiva, cualquier cliente de RA que se base en conexiones a datos y a lugares, mediante navegadores WEB (URLs), podrá beneficiarse de las ventajas de éstos y otros numerosos estándares que ya existen para los navegadores de Internet, con garantía de éxito. Sin embargo, hay muy poco hecho respecto a como los diferentes sistemas de RA pueden trabajar juntos; aquí podría residir el principal problema, pues si salimos de los centros de desarrollo y programación, los actuales sistemas de RA que están vigentes en la calle son los del equipo holandés de Raimo van der Klein, Claire Boonstra & Maarten Lens-FitzGerald (Layar) y los de IBM (Vidente), siendo precisamente Layar  la iniciativa más abierta, hasta el punto de abrir su API en julio de este año (http://layar.com/api).

Mientras la tecnología de Vidente se ha centrado en apliaciones muy concretas destinadas a usuarios con especialización tecnológica (infraestructuras, …), Layar se está dando los pasos para abrirse y llegar mejor al usuario de la calle. Convendría meditar hasta que punto puede residir aquí la clave del éxito y  propiciar nuevos modelos de negocio, pues el software o el hardware se irá robusteciendo en la medida que haya posibilidad de beneficio, pero la capacidad de los creadores de contenidos depende de la creación de un estándar abierto para la RA que permita ofrecer un adecuado nivel de información.

La estandarización es vital, pues aunque las aplicaciones individuales de RA no tengan que interactuar entre sí, muchos de ellas tendrán que hacerlo con el usuario al mismo tiempo para dar una sensación de facilidad de uso y transparencia.  Múltiples aplicaciones deberán ofrecer su producción al usuario a través de un medio único de comunicación. No se trata de inventar primero la normalización, pero las personas que están construyendo estos sistemas deberían seguir una dirección que permita a los proveedores estándares intersectoriales.

Información geográfica, RA y Turismo: enorme potencial por la coincidencia de información (GIS), comunicación (smartphone), tiempo (on-line-street) y espacio (GPS)

En España y puede que en el mundo entero, un efecto inducido de la capacidad de abrirse de la RA es el que puede estar teniendo el estandar de Layar sobre la actividad turística. Las posibilidades son muchas y muy atractivas, un buen ejemplo de ello son las ya citadas de la empresa SIGNO, una de las empresas pioneras en desarrollar aplicaciones y prospectar el potencial de esta tecnologías, como se puede ver en los ejemplos de Santiago de Compostela y el Camino de Santiago.

El protagonismo alcanzado ha sido tal que ha llegado a generar la creación y mantenimiento de un blog específico dedicado a este tema, en el que podemos ver, entre otras muchas cosas…, la creación de una aplicación (Beta) con acceso a 70.000 hoteles de todo el mundo y la capacidad de consultar mediante RA y relizar la reserva.

Está aplicación de “Hotels near YOU”  ha sido posible precisamente gracias a la integración de información y a la colaboración con el portal Booking de reservas on-line y viene a representar un importante botón de muestra de lo que estamos defendiendo en este post.

En este aspecto, las posibilidades de funciones como las del graffiti virtual pueden integrar esta tecnología en el WEB 2.0, lo que permitirá la generación de comentarios privados, opiniones, etc… que tan útiles están resultando en los portales de información turística sobre alojamientos, hoteles, rutas y demás productos de consumo, con la ventaja de ser pensamientos u opiniones dejados en lugares vinculados con GPS en casi cualquier parte del mundo, con distintos niveles de acceso o incluso el seguimiento de los comentarios o mensajes de otras personas al respecto.

En definitiva, la RA puede abrir un abanico inmenso de posibilidades a los profesionales de la información geográfica o geocodificada y si aprendemos del pasado y partimos del uso de estándares abiertos, su desarrollo en cantidad, calidad y usuarios puede ser tremendo, hasta el punto de convulsionar muchas de las formas habituales de consumir información, generando nuevas y sugerentes formas de negocio y de gestión.

En el caso de Informción Geográfica y Turismo, ya no dependeremos de acceder desde un ordenador en el punto de origen del turista (desde casa, antes de salir de viaje o desde el hotel…), ahora la Realidad Aumentada nos permitirá acceder a la información en destino, en la calle, en el momento y el espacio en el que se necesita esa información y con altos niveles de improvisación por parte del usuario, lo que diferenciará la navegación del visitante en paises desarrollados y generará “confianza” en la elección del destino.

Como especialista en Tecnologías de la Información Geográfica y Turismo mis conocimientos técnicos no me permiten profundizar más allá, en los entresijos de esta tecnología, pero no puedo evitar presumir sus enormes posibilidades de futuro.  ¿Quién sabe?… igual muy pronto, ver al típico turista desplegando un plano en la esquina de una ciudad quedará como una imagen para el recuerdo y comenzaremos ver transeúntes con un ojo puesto en el paisaje y otro en su smartphone, viendo cosas que van más allá de lo que ven los moradores habituales sin ese “ojo electrónico” de la RA.

El objetivo de esta serie de artículos es proporcionar una metodología para crear servicios de enrutamiento (routing) en portales web utilizando datos de OpenStreetMap (http://www.openstreetmap.org) que serán añadidos a una geodatabase de PostgreSQL, con la extensión PostGIS y PgRouting.

Para llevar a cabo este servicio son necesarias las siguientes fases:

1. Instalación de las extensiones PostGIS y PgRouting
2. Importación de los datos de OSM
3. Conversión a una geodatabase de PostGIS en PostgreSQL
4. Explotación de una geodatabase con PgRouting.
5. Diseño de la interfaz de usuario. Contenedor HTML y Javascript (Openlayers)
6. Creación de lógica de enrutamiento en PHP

En la medida en que vaya finalizando los capítulos serán publicados en esta web. En este primer artículo se abordarán las tres primeras fases.

OBSERVACIONES:

Para la realización del presente documento me he basado en las referencias web de los portales de PgRouting (http://pgrouting.postlbs.org/) y OpenLayers (http://openlayers.org), así como en diferentes páginas encontradas en Internet. En la medida en que se utilice información de otra fuente será convenientemente citada, salvo olvido.

ÁMBITO DE APLICACIÓN

Todas las fases se han ensayado satisfactoriamente en los siguientes entornos: Ubuntu 9.04 y Centos 5.3. (clon de Red Hat Enterpise Linux). No obstante, las indicaciones y comandos utilizados en este artículo hacen referencia a este último sistema operativo.

Partimos de la base que tenemos un servidor Linux con el sistema operativo Centos 5.3 de 64 bits, con la base de datos PostgreSQL 8.3 ya instaladas. Por defecto, Centos dispone de PostgreSQL 8.1, si bien hemos preferido añadir los repositorios para la 8.3.7. Para información sobre la instalación ver este enlace: https://projects.commandprompt.com/public/pgcore

NOTA: La instalación de PostgreSQL desde este repositorio “oficial” de PostgreSQL no ha sido todo lo gratificante que esperaba. Hay problemas de dependencias con respecto a otras librerías del sistema Centos. Esto en cambio no ocurre con Ubuntu, que por defecto tiene en su paquetería las últimas versión de esta base de datos.

APLICACIONES UTILIZADAS

• PostgreSQL 8.3
• PostGIS 1.4
• OpenLayers 2.8
• PgRouting 1.03
• Osm2pgRouting
• Osmosis

INSTRUCCIONES Y RECOMENDACIONES GENERALES:

Las instrucciones para la instalación o compilación de programas se especifican mediante comandos de la consola Linux, sin tener que recurrir a ninguna herramienta gráfica. Esta forma de actuar puede ser útil para aquellos usuarios que disponen de acceso a un servidor remoto, donde sólo se tiene acceso mediante la consola.

Con el fin de facilitar las tareas conviene crear un directorio donde descargar, descomprimir y compilar las fuentes de los programas. Para ello, crea un directorio de compilación dentro del home del usuario

$ mkdir /home/<usuario>/compilar

$ cd /home/<usuario>/compilar


NOTA: El símbolo “$” es sólo el indicativo del prompt del sistema, no es necesario escribirlo.

Otra opción es crear un directorio de fuentes (por ejemplo “src” dentro de la carpeta “usr/local/”, y trabajar siempre como root. Yo particularmente prefiero la primera opción.

INSTALACIÓN DE POSTGIS

Aunque es posible utilizar la paquetería de PostGIS que aparece en el repositorio (yum info Postgis) he preferido compilar el paquete con el fin de tener la última versión estable de PostGIS

Sí no estás interesado en compilar PostGIS, puedes instalar el paquete oficial que viene con el repositorio de Postgres para Centos. Utiliza estos comandos

Y obtendrás esta información:

Luego, como superusuario:

Compilación de PostGIS 1.4

Por suerte, PostGIS es una extensión bastante utilizada, y por tanto su compilación está muy bien detallada en el portal de Reflaction Research (http://postgis.refractions.net/)

Esta extensión requiera para su compilación de dos librerías de las que depende (dependencias), por una parte PROJ y por otra GEOS. Ambas son bien conocidas y utilizadas en multitud de programas de SIG de código abierto. Ambas son opcionales, y no son necesarias para la compilación, pero sin ellas dejariamos a PostGIS huerfano de utilidades de reproyección y geoprocesamiento.

Instalación de la librería PROJ.4

PROJ.4 (http://trac.osgeo.org/proj/) es la librería más utilizada para las proyecciones cartográficas y permite, como no podía ser de otra manera realizar conversiones entre diferentes proyecciones cartográficas.

NOTA: En el blog de Geomaticblog.net hay un excelente post de como utlizar esta librería desde aplicaciones como GDAL/OGR o GvSIG. Particularmente, me ha resultado útil para transformar datos desde ED50 a WGS84. Enlace: http://geomaticblog.net/2009/01/23/2009-01-23-ogrs_y_rejillas_ntv2/

Pasos para la compilación:

1. Descargar la fuente

$ wget http://download.osgeo.org/proj/proj-4.7.0.tar.gz

2. Descomprimirla

$ tar xzvf proj-4.7.0.tar.gz

3. Cambio de directorio

$ cd proj-4.7.0

4. Configuración y puesta a punto. El siguiente comando prepara la compilación advirtiéndonos si falta algún que otro paquete

$ ./configure

NOTA: Es posible que en este paso aparezcan errores porque falta algún paquete. Tan sólo fíjate en que es lo que falta e instálalo (con “yum” o “apt” en el caso de Ubuntu). Habitualmente serán necesarias algunas herramienta propias de la compilación, como flex, bison, make, etc. En Ubuntu tienes un paquete específico para ello: “sudo apt-get install build-essential”.

5. Compilación

$ make

6. Colocar las librerias en su sitio como “root”

$ make install

Para “impersonarse” como superusuario sólo tienes que escribir: “su -”. En Ubuntu sólo tienes que anteceder la palabra “sudo” a cualquier comando que quieras ejecutar como root. En ambos casos te pedirá la clave de acceso del administrador del sistema.

7. Comprobación

$ proj

Obtendremos lo siguiente:

Instalación de GEOS (Geometry Engine Open Source)

GEOS (http://trac.osgeo.org/geos/) es una librería que proporciona a PostGIS la capacidad de realizar geoprocesamiento. Sin ella no podriamos realizar las típicas operaciones de unión, intersección, diferencia, buffer, etc, todas ellas correspondiente a la especificación SFA (Simple Feature Access) del OGC. GEOS es un porting de la librería JTS (Java Topology Suite) en el lenguaje C++, lo que le convierte en una máquina de geoprocesos bastante eficiente.

Pasos para la compilación

1. Descarga de la fuente

$ wget http://download.osgeo.org/geos/geos-3.1.1.tar.bz2

2.Descomprimir:

$ tar -xjvf geos-3.1.1.tar.bz2

3.Cambio de directorio

$ cd geos-3.1.1

4.Configuración

$ LDFLAGS=-lstdc++ ./configure

La directiva LDFLAGS tiene como objetivo enlazar expliciatamente PostgreSQL con el estándar C++

5. Compilar

$ make

El tiempo de compilación suele ser bastante largo (en torno a los 7-10 minutos)

6. Colocar librerías en su sitio (Como usuario root):

$ make install

7. Comprobación

$ geos-config –version

Devolverá:

3.1.1

Instalar PostGIS

Sí las dos librerías anteriores han sido instaladas correctamente deberás de tener los siguientes archivos en el directorio “/usr/local/lib”. Compruébalo:

Proceso de instalación:

1. Descarga de las fuentes:

$ wget http://postgis.refractions.net/download/postgis-1.4.0.tar.gz

2. Descomprimir:

$ tar xzvf postgis-1.4.0

3. Cambiar de directorio

$ cd postgis-1.4.0

4. Configurar

Es el paso que más atención debemos de prestar, puesto que al final del comando emitirá un informe con las dependencias satisfechas

$ ./configure

Sí todo va bien obtendremos un mensaje similar a este:

5.Compilación y colocación de las librerías

$ make

$ make install (como root)

Post-instalación de PostGIS

El siguiente paso es de vital importancia y nos puede ahorrar muchos problemas en el futuro. Por defecto las librerías se instalan en el directorio ya citado (”/usr/local/lib”), sin embargo, éste directorio no es reconocido por los programas de compilación como un directorio válido para instalar librerías, por lo que es necesario indicárselo de forma expresa. Para ello como root:

1. Edita el fichero “/etc/ld.so.conf” con tu editor preferido (vi, pico, nano, etc):

$ nano /etc/ld.so.conf

Y añade las siguientes líneas al final del documento

2. Finalmente ejecuta este comando

$ /sbin/ldconfig

INSTALACIÓN DE LA LIBRERÍA PgRouting

PgRouting (http://pgrouting.postlbs.org), al igual que PostGIS, es una extensión de PostgreSQL que permite trabajar con redes

A diferencia de PostGIS, aun no tenemos un paquete que instale PgRouting que satisfaga todas sus dependencias, por ello es necesario optar por la compilación de todas y cada una de las librerías utilizadas.

Librerías de las que depende:

• BOOST (http://www.boost.org ): Es la librería principal, y la única que es obligatoria. Se trata de un basto conjunto de utilidades, entre las que destacan las referidas al análisis y explotación de grafos.
• GAUL (Genetic Algorithm Utility Library): Esta librería sólo es necesario si deseamos dotar a PostgreSQL de la utilidad de cálculo del llamado “Problema del viajante”, conocida por sus signas en inglés, TSP (Traveling Salesman Problem), es decir, proporcionar la ruta óptima pasando por varios sitios. Enlace: http://gaul.sourceforge.net/
• CGAL (Computacional Geometric Algorithm Library): Librería especializada en el cálculo y procesamiento de estructuras geométricas en 2D y 3D. En el caso de PgRouting proporciona el algoritmo de cálculo conocido como Driving Distance.

NOTA: Adicionalmente compilaremos el compilador CMAKE

BOOST

Como ya se ha comentado se trata de una librería muy ambiciosa por la gran cantidad de utilidades que engloba, de ahí que se compilación sea muy pesada (en tiempo de compilación). En los repositorios, Centos dispone actualmente de la versión 1.33.1, bastante antigua, si pensamos que la última estable es la 1.4.0. No obstante, para este artículo utilizaré la 1.39.0 que es la que tenemos más ensayada.

Con todo, de esta líbrería sólo necesitamos las utilidades de grafos (graphs)

Para ver la versión de las fuentes boost del repositorio:

$ yum info boost-devel

Sí no queremos complicarnos la vida con la compilación añade el paquete con “yum”:

$ yum install boost-devel

En Ubuntu 9.04, la versión disponible es la 1.34, sería:

$ sudo apt-get install libboost-graph-dev

Compilación de las fuentes de boost 1.39

1. Descarga las fuentes:

wget http://sourceforge.net/projects/boost/files/boost/1.39.0/boost_1_39_0.tar.bz2/download

2. Descomprimir

$ tar –xjvf boost_1_39_0.tar.bz2

3. Cambiamos al usuario administrador

$ su -

4. Instalar dependencias:

$ yum install expat-devel

$ yum install python-devel

$ yum install freetype-devel

5. Cambio de directorio

$ cd /home/<usuario>/compilar/boost_1_39_0

6. Configuración

Para obtener ayuda sobre la configuración

$ ./bootstrap.sh –help

Configuración genérica: Instala todas las librerías en este directorio

$ ./bootstrap.sh –prefix=/usr/local/

Sí sólo necesitamos compilar la librería de cabezera (header library)

$ ./bootstrap.sh –prefix=/usr/local/ –with-libraries=graph

5. Compilar

$ ./bjam install

Es posible que tengas al inicio de la compilación algún mensaje relacionado con la librería EXPAT ques es utilizada por libGraph.  Para evitar este mensaje define estas variables:

$ export EXPAT_INCLUDE=/usr/include

$ export EXPAT_LIBPATH=/usr/lib

Y de nuevo ejecuta

$ ./bjam install

NOTA: Sí deseas compilar versiones anteriores, como la 1.36 y 1.37, la compilación es más sencilla. Usa los clásicos: ./configure, make, make install

GAUL

Instalación de Gaul (librería necesaria para el algoritmo TSP -Traveling Salesman Problem)

$ wget http://nfsi.dl.sourceforge.net/sourceforge/gaul/gaul-devel-0.1849-0.tar.gz

$ tar xzvf gaul-devel-0.1849-0.tar.gz

$ ./configure –disable-slang

Instalar CMAKE

Este compilador sólo se instalará para el usuario, y no estará disponible para todos (no hacer nunca “make install” como root)

$ wget http://www.cmake.org/files/v2.4/cmake-2.4.8.tar.gz

$ tar -zxvf cmake-2.4.8.tar.gz

$ cd cmake-2.4.8

$ ./configure

Como usuario (¡no como administrador¡)

$ gmake

CGAL

Librería necesaria para utilizar el algoritmo Driving Distance). La versión que vamos a compilar es la 3.3.1, aunque existe otra más moderna (3.4). Sin lugar a dudas es la libraría que más problemas ofrece.

$ wget ftp://ftp.mpi-sb.mpg.de/pub/outgoing/CGAL/CGAL-3.3.1.tar.gz

$ tar xzvf CGAL-3.3.1.tar.gz

$ cd CGAL-3.3.1

Compilar como root:

$ ./install_cgal –prefix=/usr/local –with-boost=n –without-autofind -ni /usr/bin/g++

Las librerías y los include se colocan en estos directorios:

/usr/local/lib/

/usr/local/include/

INSTALACIÓN DE LA LIBRERÍA PGROUTING

Una vez satisfechas todas las dependencias de librerías vamos a compilar PgRouting

1. Primero nos descargamos las fuentes desde el repositorio subversión. Recuerda que debes de tener instalada dicha utilidad (“yum install subversión”)

$ svn checkout http://pgrouting.postlbs.org/svn/pgrouting/trunk pgrouting

2. Nos cambiamos al directorio

$ cd pgrouting

3. Configuramos

Para ello utilizamos el compilador CMAKE que ya tenemos disponibles.

Compilar (no olvides el punto al final del comando)

La sintaxis de compilación es:

<ruta al ejecutable CMAKE) .

NOTA: No olvides el punto al final. Es para indicarle que compile el directorio actual

Con ello instalaremos la librería, pero apenas nos servirá de nada porque no hemos hecho referencia a que queremos los algoritmos “Driving Distance (DD)” y TSP.

Por ello cambia lo anterior por esto

# ../cmake-2.4.8/bin/cmake -DWITH_TSP=ON -DWITH_DD=ON .

Resultado del configure

4. Finalmente generamos la librería

# make

Resultado de la compilación

5. Por último colocamos los archivos en su sitio (como root):

$ make install

Resultados

Ya tenemos PgRouting disponible

OSM2PGROUTING

Descripción:

Se trata de una utilidad que permite convertir un fichero de OpenStreetMap, en formato OSM o XML, en una base de datos PostgreSQL que tenga instaladas las extensiones PostGIS y PgRouting.

Esta utilidad está específicamente diseñada para OSM, y realiza un especial tratamiento de los datos teniendo en cuenta los tags OSM, de forma tal que es capaz de generar un grafo adecuado para el ruteo. Bien es cierto que tenemos otras posibilidades, como descargar un shapefile de datos OSM de cualquiera de los servidores existentes (Geofabrik, CloudMade) y convertirlos a PostgreSQL con la utilidad “shp2pgsql” provista por PostGIS, sin embargo el resultado no será el mismo. Veamos un ejemplo

Fíjate en esta zona donde tenemos vías que aparecen a distinto nivel: http://www.openstreetmap.org/?lat=38.379259&lon=-0.452301&zoom=18&layers=B000FTF

Sí no utilizamos esta utilidad se generará un nodo por cada cruce de vías, independientemente de que si están o no a diferentes niveles. Osm2pgrouting entiende los tags de OSM y evita colocar nodos donde no le corresponde.

Nodos en OpenStreetMap. Las vías es azul contienen el tag bridge=yes, y por tanto están a diferente nivel

Compilar osm2pgrouting

$ svn checkout http://pgrouting.postlbs.org/svn/pgrouting/tools/osm2pgrouting/trunk osm2pgrouting

$ cd osm2pgrouting

$ make

Como administrador:

$ make install

CREAR UNA PLANTILLA DE GEODATABASE CON POSTGIS Y PGROUTING

Este es quizás el momento más excitante de todos, puesto que vamos a crear una base de datos con datos ya normalizados para ser explotado con las utilidades de PgRouting.

El proceso siempre es el mismo:

1. Crear la base de datos
2. Añadirle la funcionalidad de PostGIS
3. Añadirle la funcionalidad de PgRouting
4. Cargar datos desde OSM a la base de datos (osm2pgsql)
5. Crear topología
6. Explotar la base de datos

Creación de una plantilla de base de datos

Es una buena práctica tener creada una plantilla de base de datos con todas las extensiones ya incluidas para que podamos utilizarla en cualquier geodatabase que creemos.

Puesto que estamos intentando cargar datos desde OSM es conveniente utilizar una codificación de caracteres que albergue todas las posibilidades multilenguaje que se pueden dar (alfabetización árabe, cirílica, etc)

1. Sín más preámbulos creamos la base de datos

Sintaxis:

$ createdb –h <host> –U <user> -p <puerto> -E <código codificación <nombre base de datos>

En nuestro caso este es el resultado

$ createdb -U postgres -E UTF8 routing

1. PostGIS exige que la base de datos tenga cargado el lenguaje procedural Pl/PgSql. De hecho la gran mayoría de las funciones de PostGIS y PgRouting están en este lenguaje:

$ createlang -U postgres plpgsql <nombre base de datos>

$ createlang -U postgres plpgsql routing

1. Añadir la funcionalidad PostGIS

Ahora necesitamos saber donde ha instalado Postgis los ficheros SQL necesarios para crear la geodatabase. Recomendamos utilizar el comando find para encontrarlos

Para las versiones < 1.4

$ find /usr/ -name lwpostgis.sql

Para versiones >= 1.4

$ find /usr/ -name postgis.sql

/usr/share/lwpostgis.sql

Lo mismo para las referencias espacials

$ find /usr/ -name spatial_ref_sys.sql

/usr/share/spatial_ref_sys.sql

Ahora sólo queda cargar el fichero de funcionalidades en la base de datos:

Para la versión 1.3.x

$ psql -U postgres -f /usr/share/lwpostgis.sql routing

$ psql -U postgres -f /usr/share/spatial_ref_sys.sql routing

Para la version 1.4

$ psql -U postgres -f /usr/share/pgsql/contrib/postgis.sql routing

$ psql -U postgres -f /usr/share/pgsql/contrib/spatial_ref_sys.sql routing

1. Añadir la funcionalidad PgRouting

Más de lo mismo. Primero añadimos la funcionalidad básica:

$ psql -U postgres -f /usr/share/postlbs/routing_core.sql routing

$ psql -U postgres -f /usr/share/postlbs/routing_core_wrappers.sql routing

$ psql -U postgres -f /usr/share/postlbs/routing_topology.sql routing

1. Luego la funcionalidad para el algoritmo TSP (opcional)

$ psql -U postgres -f /usr/share/postlbs/routing_tsp.sql routing

$ psql -U postgres -f /usr/share/postlbs/routing_tsp_wrappers.sql routing

1. Por ultimo la funcionalidad para el algoritmo “Driving Distance”

$ psql -U postgres -f /usr/share/postlbs/routing_dd.sql routing

$ psql -U postgres -f /usr/share/postlbs/routing_dd_wrappers.sql routing

1. Vamos a comprobar que todo está bien.

Accedemos a la base de datos creada:

$ psql -U postgres routing

routing=# select postgis_full_version();

Devolverá:

1. Últimos retoques:

Con el objetivo de utilizar en el futuro OpenLayers, y con el fin de arbitrar un sistema de proyección que sea común para el uso de varios proveedores de datos (Google Maps, Yahoo Maps, Microsoft Live Maps, etc), vamos a incluir un nuevo registro en la tabla spatial_ref_sys, para añadir la denominada proyección esférica de Mercator, a veces conocida como “proyección Google”, por ser ésta la que se utiliza en en Google Maps. Lo interesante de esta proyección, a diferencia del sistema geodésico mundial con datum WGS84 es que las unidades están en metros, lo que facilita la compresión de los cálculos de distancias, en contraposición a la medición en grados decimales de arco de circunferencia. Más información aquí:

http://trac.openlayers.org/wiki/SphericalMercator

En este enlace tienes una imagen de gran formato de la tierra con esta proyección: http://designintelligences.files.wordpress.com/2009/03/mercator-projection1.jpg

En definitiva, sólo tenemos que añadir este registro:

La proyección esférica de Mercator tiene el código 900913, según el European Petroleum Survey Group (EPSG) mientras que OpenStreetMap utiliza como proyección global  predeterminada el geodésico mundial con datum WGS84, cuyo código es 4326.

Ya nos podemos salir de la consola de Postgresql

routing=# \q

1. Crear una geodatabase a partir de la plantilla creada

Bueno ya está hecho todo el trabajo de la plantilla, ahora el proceso de crear una nueva base de datos con todo ya preparado es sólo una línea;

createdb -U <usuario> -T <plantilla> <nueva bd>

En nuestro ejemplo sería

createdb -U postgres -T routing osmtest

Truco del día:

Sí tu servidor no tienes un sistema gráfico funcionando y necesitas llevar un fichero desde tu ordenador al servidor utiliza el comando “scp”. Es muy práctico

Sintaxis:

$ scp <fichero de tu ordenador>@<hostname o IP>:<directorio del servidor donde copiar el fichero>

Ejemplo:

$ scp OSM/alicante_30_09_2009.osm jose@www.gisandchips.org:/home/jose/compilar/osm2pgrouting

DESCARGAR DATOS DE OPENSTREETMAP

Esto ya va tomando color. Queda lo más bonito. ¡Paciencia!

Tenemos 2 opciones:

a)     Descargar un fichero OSM ya creado en cualquiera de los portales web que hay a tal efecto (Geofabrik (http://download.geofabrik.de/osm/) , CloudMade (http://downloads.cloudmade.com/) , etc)

Ejemplo:

Descargar OSM de España (69 Mb)

$ wget http://download.geofabrik.de/osm/europe/spain.osm.bz2

Descomprimir

$ tar -xjvf spain.osm.bz2

a)     Recortar una zona del planet.osm con Osmosis (http://wiki.openstreetmap.org/wiki/Osmosis)

$ wget http://dev.openstreetmap.org/~bretth/osmosis-build/osmosis-latest-bin.tar.gz

$ tar xzvf osmosis-latest-bin.tar.gz

$ cd osmosis-0.31/ bin/

La sintaxis básica es la siguiente:

$./osmosis –read-xml <fichero osm matriz> –bb left=<coord oeste> right<coord este> top=<coord norte> bottom=<coord sur> –write-xml <nombre fichero a crear extraido de matriz>

Por supuesto las coordenadas deben de estar en grados decimales del WGS84. Pero, ¿de dónde las saco?

Esta vez viene en nuestra ayuda el portal www.openstreetmap.org que viene con una utilidad (pestaña “Exportar”) para proporcionarnos información sobre la caja que estamos visualizando  en el mapa

Ejemplo práctico a un barrio de Alicante

$./osmosis –read-xml /home/jose/OSM/alicante_30_09_2009.osm –bb left=-0.4359 right=-0.42006 top=38.37225 bottom=38.36192 –write-xml mibarrio.osm

IMPORTAR UN OSM EN LA GEODATABASE

Después de este tortuoso camino, ya queda lo más fácil importar el OSM, utilizando “osm2pgrouting”. La sintaxis es la siguiente:

$ ./osm2pgrouting -file <fichero osm> -conf <fichero configuración>  -dbname <base de datos> -user <usuario>

Ló único extraño aquí es el fichero de configuración, que es un XML donde se incluyen las tipologías de la vías  que queremos cargar a la base de datos (según OSM: motorway, trunk, primary, secondary, tertiary, residential, etc.). En las fuentes aparece un XML de ejemplo que nos puede servir. Debemos de tener en cuenta que en función de nuestros objetivos utilizaremos unas vías u otras. Por ejemplo, sí sólo queremos las grandes vías nos quedaremos con motorway y trunks. Sí sólo nos interesa el tema caminos rurales y rutas ciclistas nos toca trabajar el XML.

Ejemplo:

./osm2pgrouting -file ./alicante_30_09_2009.osm -conf ./mapconfig.xml -dbname osmtest -user postgres

NOTA: Este proceso suele ser bastante largo, y estará en función del tamaño del OSM. Como ejemplo, el área metropolitana de Alicante tardó unos 5 minutos, en un ordenador bien dotado. Toda España nos llevaría unas cuantas horas.

Tras un periodo de tiempo verás este mensaje

Para comprobar que tablas se han creado:

Entramos en la base de datos

psql -U postgres osmtest

Listamos las tablas:

osmtest=# \d

La tabla que contiene la geometría es ways;

CREACIÓN DE TOPOLOGÍA DE RED

Si nos fijamos la tabla ways tiene vacíos los campos source y target, que son los identificadores de nodo. Es necesario crear topología. Para ello recurrimos a una función topológica de pgrouting: “assign_vertex_id”

Lo único que tenemos es un identificador de arco (gid)

Para el caso de datos procedentes de OSM, al estar los datos en grados decimales y la proyección en geodésica (4326) la tolerancia a aplicar es muy pequeña. 0.00001

SELECT assign_vertex_id(‘ways’, 0.00001, ‘the_geom’, ‘gid’);

Listado de tablas

Ahora la tabla ways está preparada para topología.

Con este extenso post queda por finalizada la primera parte sobre PgRouting con OpenStreetMap. Nos esperan dos nuevos artículos que espero sean de vuestro interés:

1. Explotación de una geodatabase con OpenStreetMap y PgRouting
2. Diseño de una interfaz web con OpenLayers para el análisis de redes.

Este documento no pretende ser una guía de desarrollo de gvSIG 2.0.  Si se quiere disponer de toda la información de desarrollo es aconsejable visitar la web de documentación del proyecto.

El primer paso es crear una carpeta en nuestro sistema donde vamos a situar todos los proyectos que nos van a hacer falta, que serán tanto nuestro proyecto del Hola Mundo como todos los proyectos mínimos necesarios para poder generar un gvSIG 2.0. Otra opción que no está contemplada en este tutoria es la de poder instalar nuestra extensión en una versión de gvSIG previemente instalada desde un instalador.

Una vez creada la carpeta hay que abrir el Eclipse e indicarle establecer la carpeta que hemos creado como workspace. Para ello tendremos que ir a la opción “File->Switch Workspace->Other” y seleccionar la carpeta que hemos creado anteriormente.

El siguiente paso será descargarnos el proyecto “build” desde el repositorio de gvSIG. Este proyecto es necesario para poder construir nuestro sistema y es el único proyecto que hay que bajar manualmente. Para ello hay que abrir la vista de SVN del Eclipse seleccionando la opción “Window -> Open Perspective -> Other” y hay que seleccionar la opción “SVN Repository Exploring”. Si no aparece esta opción es porque no se ha instalado ningún plugin de SVN.

A continuación se tiene que añadir manualmente el repositorio de gvSIG desde el que hay que descargar el proyecto “build”. Para ello hay que pulsar con el botón derecho del ratón sobre la ventana “SVN Repositories” y se abrirá una nueva ventana donde hay que introducir la dirección del repositorio de gvSIG (http://subversion.gvsig.org/gvSIG). Pulsaremos en “Finish” y si todo ha funcionado correctamente deberá aparecer el repositorio en la lista de servidores.

La lista de servidores es una lista en forma de árbol que podremos ir desplegando haciendo un doble “click” en cada uno de los nodos del árbol. Hay que abrir el servidor que hemos añadido y tendremos que buscar la ruta “branches -> v2_0_0_prep -> build”. Una vez estemos en ella, pulsamos con el botón derecho del ratón sobre la carpeta y seleccionamos la opción “Check Out” que descargará el proyecto en nuestro workspace.

Ahora hay que ir a la vista de Java para poder ver el proyecto que acabamos de bajar. Para ello hay que seleccionar la opción “Window -> Open Perspective -> Java”. Si todo ha ido bien el proyecto “build” se encontrará en la vista “Package”.

A continuación vamos a abrir la vista de Ant desde la cual vamos a poder ejecutar algunos objetivos automáticamente. Para ello hay que ir al menú “Window -> Show View -> Ant” y se abrirá una ventana nueva llamada “Ant”. El proyecto build tiene en su carpeta raíz un fichero llamado “build.xml” que contiene todos los objetivos que podemos ejecutar. Si pulsamos sobre ese fichero y sin soltar lo arrastramos y lo dejamos caer sobre la ventana de “Ant” automáticamente aparecerán los objetivos definidos en el fichero.

Lo primero que tenemos que hacer es modificar la configuración del Eclipse con algunos parámetros que necesitamos. Se puede hacer manualmente, pero para facilitar la configuración se ha creado un objetivo de Ant que lo hace todo por nosotros. Para ello tenemos que ir a la ventana de Ant y hacer un doble “click” en la opción “mvn-configure-eclipse-workspace”. Si todo ha funcionado correctamente se abrirá una ventana donde tendremos que escribir la ruta donde se encuentra el workspace que queremos configurar, que por defecto será el workspace actual. Pulsaremos en OK y esperaremos a que se ejecute el comando con éxito utilizando para ello la vista “Console”.

Una vez que ya tenemos el workspace configurado correctamente vamos a bajarnos los fuentes del gvSIG. Para ello debemos desplegar el proyecto “build” e ir a la carpeta “projects” donde veremos unas cuantas carpetas que se corresponden a grupos de proyectos de gvSIG. Nosotros necesitamos lo mínimo para poder arrancar un gvSIG, así que tendremos que desplegar la carpeta “gvsig-base”, pinchar con el botón izquierdo del ratón sobre el archivo “build.xml” y arrastrarlo hasta la vista de Ant.

Ahora tendremos en la vista de Ant dos configuraciones diferentes (gvsig-build-config y gvsig-group-base), por lo que hay que ir con precaución a la hora de seleccionar un objetivo. Seleccionaremos gvsig-group-base y a continuación haremos un doble “click” en el objetivo “svm.checkout.all”. Se abrirá una ventana que servirá para poder configurar el servidor desde el que vamos a descargar los fuentes. Por defecto no hay que modificar nada, salvo la versión del conector de SVN que tenemos instalada en el Eclipse. Si no se conoce  la versión, se puede consultar en “Window -> Preferences -> Team -> SVN -> SVN Connector”.

Pulsamos en “Ok” y si todo ha funcionado correctamente veremos en la ventana “Console” como la aplicación empieza a descargarse diversos proyectos. Una vez que haya terminado tendremos que importar los proyectos descargados. Para ello tenemos que pulsar con el botón derecho sobre la ventana de “Package” y seleccionar la opción “Import”. A continuación debemos seleccionar “General -> Existing Projects into Workspace” y pulsa en “Next”. Seleccionamos la carpeta de nuestro workspace y veremos como aparece una lista de proyectos en la ventana. Pulsamos en “Finish” y automáticamente aparecen todos los proyectos que forman el gvSIG base en la ventana “Package”.

Ahora vamos a compilar todos los fuentes y vamos a arrancar gvSIG. Para ello hay que ir a la vista de Ant y seleccionando “gvSIG-group-base” ejecutaremos el objetivo “mvn-install”. Este objetivo compilará todos los proyectos que nos hemos bajado y creará una instalación de gvSIG en la carpeta “build -> product”. En la ventana “console” podremos ver el progreso de la compilación. En la actualidad gvSIG 2.0 está en fase de desarrollo y es posible que el comando anterior falle porque ha fallado alguno de los tests unitarios. Si es el caso hay que repetir el proceso anterior pero ejecutando “mv-install-without-tests”, que hace lo mismo que el install pero sin generar ni ejecutar los tests unitarios.

Si todo ha funcionado correctamente ya estamos en disposición de poder ejecutar gvSIG 2.0 desde el Eclipse. Para eso tenemos que seleccionar la opción “Run -> Debug Configurations -> Java Application”  y seleccionar el lanzador de nuestro sistema operativo. Al pulsar en “Debug” debería arrancar gvSIG. Si no lo hace y sale un mensaje diciendo que no se encuentra alguna librería, es porque Eclipse “no se ha dado cuenta” de que se ha instalado la versión de gvSIG en la carpeta “build/product”. Refrescamos esta carpeta y volvemos a arrancar la aplicación.

Ahora que ya tenemos la aplicación vamos a crear nuestra extensión para gvSIG. Primero, deberemos decidir si lo que vamos a crear es una librería o una extensión. La diferencia principalmente es que las librerías no tienen interfaz de usuario y no dependen de Andami mientras que las extensiones sí que dependen de Andami. Nuestra idea es mostrar el “Hola Mundo” en una nueva ventana por lo que vamos a generar una extensión.

Para ellos seleccionamos la opción “Run -> External Tools -> External Tools configurations”  y en la opción “Ant Build” seleccionamos y ejecutamos “create extension”. Se abrirá una ventana dónde tendremos que insertar algunos de los parámetros de configuración de “Maven”. El único que nos interesa en estos momentos en el “Maven artifactid”, cuyo valor corresponderá con el nombre del proyecto de Eclipse que se va a crear. en nuestro caso escribiremos “org.gvsig.holamundo” y pulsaremos el botón “OK”. En la ventana “Console” podremos seguir el proceso de creación del nuevo proyecto.

Una vez que tenemos el proyecto creado hay que importarlo del mismo modo que importamos anteriormente todos los proyectos que nos bajamos del repositorio. El proyecto que se ha creado ha tomado como base la extensión de centrar una vista en un punto por lo que tiene algunas clases que no vamos a utilizar. Podemos eliminar todas las clases del proyecto.

Ahora vamos a crear una clase llamada “HolaMundoExtension” que herede de “org.gvsig.andami.plugins.Extension” en el paquete “org.gvsig.holamundo” que será nuestro punto de entrada cuando el usuario seleccione la opción de menú “Hola Mundo” desde la aplicación.  Tendremos que hacer que los métodos “isVisible” e “isEnabled” devuelvan “true” y en el método “execute”pondremos el código que muestre una ventana con un “Hola Mundo”. La clase quedará del siguiente modo:

import java.awt.Component;
import javax.swing.JOptionPane;
import org.gvsig.andami.PluginServices;
import org.gvsig.andami.plugins.Extension;

public class HolaMundoExtension extends Extension {

public void execute(String actionCommand) {
JOptionPane.showMessageDialog((Component)PluginServices.getMainFrame(), "Hola Mundo");
}

public void initialize() {

}

public boolean isEnabled() {
return true;
}

public boolean isVisible() {
return true;
}
}

Ahora tenemos que “enganchar” una opción de menú con nuestra clase editando el fichero “src/main/resources/config.xml” del modo que se muestra a continuación:

<?xml version="1.0" encoding="ISO-8859-1"?>
<plugin-config>
<libraries library-dir="lib"/>
<depends plugin-name="org.gvsig.app"/>
<resourceBundle name="text"/>
<extensions>
<extension class-name="org.gvsig.helloworld.HolaMundoExtension"
description="Extensión que hace un hola mundo"
active="true">
<menu text="Prueba/Hola Mundo"
tooltip="Hola Mundo"
action-command=""/>
</extension>
</extensions>
</plugin-config>

Para poder probar nuestra extensión, antes debemos compilarla e instalarla en gvSIG. Para ello debemos de seleccionar nuestro proyecto y a continuación ejecutar el objetivo “mvn install” que encontraremos en “Run -> External Tools -> External Tools configurations -> Ant Build”. Si todo funciona correctamente, deberemos arrancar gvSIG del mismo modo que lo habíamos hecho anteriormente y aparecerá una nueva entrada en la barra de menú llamana “Prueba” desde la que podremos ejecutar nuestra extensión.

Si se quiere profundizar un poco más para entender qué contiene un fichero “config.xml” o cómo se crean extensiones más complejas se puede consultar la web de documentación del proyecto gvSIG.

]]> http://www.gisandchips.org/2009/10/01/hola-mundo-con-gvsig-2-0-y-con-eclipse/feed/ 2 http://www.gisandchips.org/2009/09/24/integracion-de-r-en-postgresql-mi-primera-funcion-en-plr/ http://www.gisandchips.org/2009/09/24/integracion-de-r-en-postgresql-mi-primera-funcion-en-plr/#comments Thu, 24 Sep 2009 08:49:58 +0000 benizar http://www.gisandchips.org/?p=165 En primer lugar, y para que ninguno de vosotros tenga impresión que no voy a hablar nunca de GIS, me gustaría tranquilizaros, y recordaros que en próximos artículos, yo o a quien le apetezca participar en este hilo, pasaremos a comentar usos de todo esto que estamos viendo orientado al tratamiento de la información espacial. Si hay alguien que quiera compartir sus experiencias con temas de R será bien recibido.

Este segundo artículo sobre tecnologías útiles para explotar toda la potencia de R se centra en el uso de R desde el PostgreSQL.

Como todos sabéis, tradicionalmente los Sistemas Gestores de Bases de Datos (SGBD), como PostgreSQL, Oracle, MySQL o Access han sido diseñados para guardar y gestionar gran cantidad de datos, por ello las posibilidades de análisis y salidas gráficas se han delegado mayormente en otros softwares como hojas de cálculo, paquetes estadísticos como SPSS, R o en nuestro caso en softwares SIG… pero eso se acabó    .

pl/R es un lenguaje de programación procedural que permite contar con toda la potencia de cálculo y salidas gráficas del paquete estadístico R, así como de su lenguaje de programación desde dentro de funciones de PostgreSQL.

Los requisitos básicos para comenzar a trabajar con pl/R son, como no, tener instalado PostgreSQL (he trabajado sin demasiados problemas con las versiones 8.2 y 8.3), tener pl/R instalado, y crear una base de datos en PostgreSQL donde añadimos el nuevo lenguaje procedural.

Todo lo que necesitamos para iniciarnos lo podemos encontrar en la página WEB del creador de pl/R, Joe Conway (http://www.joeconway.com/plr/ ), donde nos descargaremos los ficheros para la instalación tanto para Windows como para Linux. También hay documentación para dar los primeros pasos y unos cuantos más. Esta presentación os ayudará bastante (http://www.joeconway.com/oscon-pres-2003-1.pdf ). Os recomiendo leer todo lo que podáis, incluso su Curriculum que está en la página principal no tiene desperdicio.

Hay mucha documentación en Internet y ejemplos de funciones básicas. Nosotros para trabajar con algo que ya conocemos, volveremos a utilizar la función hist() de R para obtener el histograma de cualquier campo numérico que podamos tener en una tabla de nuestra base de datos.

Cualquiera que haya trabajado bien con R, bien con funciones de PostgreSQL en general encontrará rápidamente los primeros problemas o desventajas, si es que se pueden llamar así, de usar pl/R. En cualquiera de los dos casos, normalmente tendremos que aprender a usar una nueva herramienta (PostgreSQL o R), lo cual es un nuevo mundo. Depurar las funciones de pl/R puede ser engorroso si se hace directamente, y normalmente los procesos serán más lentos, proporcionalmente, que si trabajásemos solamente en uno de los dos lados del espejo.  Pero ahora os diré las ventajas que puedo destacar más rápidamente:

• Podemos ejecutar nuestras nuevas funciones mediante una sencilla expresión de SQL,
• las funciones estarán siempre junto con los datos (acabando con la importación-exportación),
• tenemos la posibilidad de usar las funciones desde PHP y
• un potente SGBD se encargará de gestionar el manejo de los datos, lo cual es muy bueno cuando se trabaja con grandes volúmenes de información.

Hay más ventajas, pero creo que para empezar no está nada mal.

Mi primera función en pl/R

Una vez lo tenemos todo instalado, os recomiendo empezar probando que todo funciona bien desde el GUI de R, ya que desde pl/R nos será más complicada la depuración.

La función que paso a detallar está pensada para usarla en local y que la probéis con vuestros propios datos (numéricos; si no lo son veréis un mensaje de error). Se trata de crear un histograma y guardarlo como imagen.

Como os podéis dar cuenta parece una función de pl/pgSQL solo que cambiamos el lenguaje al final y metemos directamente código de R entre $BODYs o comillas simples, aunque resulta más práctico el $ por si dentro de la función necesitamos usar comillas de dos tipos.

Los comentarios de la función pueden ir con # igual que en R.

A continuación tenemos el código para crear la nueva función:

CREATE OR REPLACE FUNCTION _plr_hist(text, text)
RETURNS text AS
$BODY$
select = 'select '
campo = arg1
from = ' from '
tabla = arg2
selection = paste(select, campo, from, tabla, sep='');

## Ejecutamos la consulta y la almacenamos en el objeto "sql";
sql <- pg.spi.exec (selection);

## Lo que obtengamos a partir de aquí se imprimirá en un pdf...
dir='c:/temp/';
nam= arg1;
ext='.png';
newfile=paste(dir,nam,ext, sep='')
png(newfile);

hist(sql[,1], xlab = campo, ylab='frecuencias', main= campo, col='blue', ylim=c(0,20));

## Hasta aquí
dev.off();

## Si trabajamos en linux querremos hacer algo como lo siguiente
## para asignar privilegios de lectura a todos los usuarios de linux
##sys1='chmod go+r'
##sys2=paste(sys1, '', newfile)
##system(sys2)

## Esto devuelve un mensaje al terminar la función
print1='¡¡¡Ya está!!!, ¡¡¡mira que gráfico más chulo en'
print2=paste(print1, '', newfile, sep='')
print (print2);

$BODY$
LANGUAGE 'plr' VOLATILE

Dentro de la función hay que destacar el empleo de pg.spi.exec(),  para uso de los desarrolladores de PostgreSQL, que ejecuta una expresión dada.

Una vez creada nuestra función la podremos ejecutar de un modo muy sencillo. Fijaos que bueno que es esto     :

select _plr_hist('un campo numérico', 'tabla');

Y obtenemos nuestra gráfica en la carpeta especificada.

Algunos comentarios sobre todo esto:

Viéndolo ya funcionar parece que nada “malo” pueda pasarnos. A este respecto, uno de los aspectos que más problemas me creó en su día es lo relacionado con los derechos del usuario Postgres en el SO, tanto en Linux como en Windows. La solución en linux viene dada y comentada en el código de más arriba. Con “chmod go+r” damos derechos de lectura a todos los usuarios. Lo que no me imaginaba nunca es que en Windows también iba a tener problemas. Resulta que el usuario que ejecuta el postmaster de Postgresql es “postgres”, que no dispone de derechos de escritura (no se si hay otros problemas) en “c:\”. Cuando se trata de crear una salida gráfica a c:\, el interprete de pl/R indica que no se puede iniciar el device(). Esto me llevó algún dolor de cabeza pues en Windows suelo hacer todas mis primeras pruebas directamente en c:\. En el ejemplo de antes trabajamos en un directorio creado a propósito. Sobre esto último podemos consultar en http://pgfoundry.org/pipermail/plr-general/2009-June/000264.html .

Referencias:

Solamente recordaros lo esencial de la página de Joe Conway (http://www.joeconway.com/plr/ ). También os recomiendo entrar en http://www.bostongis.com/ donde hay un hilo de 3 artículos explicando distintos temas relacionados con pl/R. El primero es una introducción bastante detallada, el segundo es trata la creación de polígonos de Voronoi en PostgreSQL usando PostGIS y pl/R (muy recomendable, y avanzado), y el último es un ejemplo de uso de RGDAL.

——————————————————————-

Si quereis contactar podeis enviarme un email (asunto: gisandchips):

Benito M. Zaragozí

benito.zaragozi@ua.es