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!!

El problema de las extensiones de SQLite

SpatiaLite es fundamentalmente una librería (libspatialite) que actúa como extensión de SQLite: explota el índice R-Tree de SQLite y añade el tipo Geometry y una serie de funciones que a su vez invocan a las de GEOS y PROJ. El resultado, al igual que el tándem PostgreSQL / PostGIS, es una implementación de la especificación “Simple Features for SQL” del OGC pero sin necesidad de una infraestructura cliente-servidor. Este tipo de librerías, que contienen funciones que extienden las propias de SQLite, se cargan dinámicamente, es decir, es el desarrollador el encargado de enlazarlas en tiempo de ejecución en el ámbito de una conexión de base de datos. El problema es que este mecanismo de extensión constituye a su vez un agujero de seguridad, un “coladero” de software malicioso. Así que, por defecto, las distros de Linux proporcionan el binario de SQLite compilado de forma que no se autoriza la carga dinámica de extensiones. Supongo que al final, quienes lo necesitan, optan por compilar su propio binario de SQLite o utilizar el que proporciona SpatiaLite, donde la extensión está estáticamente enlazada. Los que trabajáis con Mono tenéis ahora otra opción más.

Org.Gisandchips.Sqlite

Podéis descargar el código fuente de este proveedor ADO.NET para SQLite desde el repositorio SVN de Gis&Chips:

svn co http://www.gisandchips.org/svn/sqliteprovider

Para vuestra comodidad, os proporciono el fichero de proyecto MonoDevelop. Yo compilo sin problemas en una máquina Ubuntu 11.04, con Mono 2.10, MonoDevelop 2.6 y bajo el framework .NET 4.

Si echáis un vistazo al código comprobaréis que se trata del mismo proveedor Mono.Data.Sqlite (obtenido de la master branch del repositorio público de Mono en github) con los siguientes añadidos:

• Wrappers para las funciones enable_load_extension() and load_extension() del API de sqlite3.
• Método público SqliteConnection.LoadExtension() que permite cargar dinámicamente extensiones de sqlite3.

El siguiente código de ejemplo es suficientemente explicativo:

using (var cn = new SqliteConnection ("Data Source=path/file.sqlite")) {
  cn.Open ();
  cn.LoadExtension ("libspatialite.so.2");
  //your sql commands follow
}

Respecto a la licencia, me remito a la de Mono (MIT), que es la más permisiva y entiendo que compatible con las instrucciones del autor original de System.Data.SQLite, Robert Simpson, quien liberó este proveedor como de dominio público. Que lo disfrutéis.

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/04/edicion-de-geometrias-en-nts-con-coordinatearrayfilter/ http://www.gisandchips.org/2009/11/04/edicion-de-geometrias-en-nts-con-coordinatearrayfilter/#comments Wed, 04 Nov 2009 11:09:09 +0000 josetomas http://www.gisandchips.org/?p=747 Java Topology Suite (JTS) es una librería que resuelve problemas complejos y en la que sus arquitectos han recurrido al uso exhaustivo de patrones de diseño de software como medio de gestionar eficientemente dicha complejidad. Como muestra baste mencionar que los desarrolladores debemos asumir desde el principio el factory pattern que implementa la clase GeometryFactory que empleamos en la construcción de objetos geométricos. El hecho de que JTS haga uso de patrones de diseño es una muestra más de su fiabilidad, aunque en ocasiones (sobretodo si hay carencia de documentación) también implica un esfuerzo extra por nuestra parte a la hora de entender cómo se solucionan determinados casos de uso. Uno de esos casos en los que la solución no se evidencia a primera vista es la edición de los vértices de una geometría, así que en este  artículo os muestro código de ejemplo para el porting de JTS a C#, NetTopologySuite (NTS) en su versión 1.2, que os permitirá introduciros en el manejo del interface ICoordinateFilter para la manipulación geométrica.

Quizá me equivoque, pero creo que no se puede calificar JTS/NTS como un “framework” para el desarrollo de herramientas de  manipulación de geometrías (e.g. aplicaciones tipo CAD). El diseño de este API promueve más bien la idea de inmutabilidad de un objeto geométrico a lo largo de su ciclo de vida (aunque no hay un mecanimo que fuerze dicha inmutabilidad), y se centra en la modelización a bajo nivel de las tareas de cálculo topológico y análisis espacial, y en la exactitud de los resultados derivados de un geoproceso, todo ello en función de las recomendaciones del Open Geospatial Consortium.

Pero es probable que, en algún punto de una secuencia de geoprocesamiento, necesitemos manipular las coordenadas de una geometría (por ejemplo, forzar una corrección de forma transparente para el  usuario). Asumiendo que el array de coordenadas almacena la secuencia de vértices actual en lugar de una copia (que la propiedad Coordinates sea o no una copia depende de la secuencia de coordenadas empleada en la construcción de la geometría; tenéis más información sobre esto en el capítulo 8 de la guía del desarrollador de JTS), nada nos impide editar diréctamente los valores en ese array. También podríamos copiar dicho array, operar sobre los vértices en cuestión, instanciar una nueva geometría y desechar la antigua. Discutir sobre la idoneidad de estas soluciones no es objeto de este artículo. Lo que interesa es que sepamos que el propio API proporciona otras vías específicas para la edición de vértices.

En concreto, si tan sólo necesitamos operar con las coordenadas existentes (no añadir ni borrar), NTS proporciona el interfaz ICoordinateFilter, a partir del cual pueden derivarse clases que implementen el visitor pattern para operar con la lista de coordenadas de cualquier tipo de geometría. Cada desarrollador puede implementar sus propias operaciones o filtros de coordenadas a conveniencia, pero NTS ya proporciona unos cuantos: UniqueCoordinateArrayFilter, CoordinateCountFilter y, el más simple y objeto de nuestro interés,  CoordinateArrayFilter, que da acceso al array completo de coordenadas para su manipulación.

Veamos un ejemplo

Suponed que tenemos el siguiente LineString:

LINESTRING (100 100,  150 180,  200 210,
            210 140,  100 110,  100 100)

Si lo visualizárais en vuestro cliente favorito observaríais algo similar a esto:

Esta geometría presenta una autointersección que NTS permite detectar de diversas formas. Nosotros nos centraremos en corregirla aplicando un criterio muy simple: intercambiaremos los valores de las coordenadas en las posiciones 0 y 4. Aquí tenéis el código fuente de esta operación de desplazamiento de vértices:

using System;
using GisSharpBlog.NetTopologySuite.Geometries;
using GisSharpBlog.NetTopologySuite.IO;
using GisSharpBlog.NetTopologySuite.Utilities;

namespace CoordFilter
{
 class Program
 {
  public static void Main(string[] args)
  {
   string wkt = "LINESTRING (100 100,  150 180,  200 210, 210 140,  100 110,  100 100)";
   WKTReader r = new WKTReader();
   Geometry g = r.Read(wkt);
   //Creamos sendas copias de las coordenadas objeto de desplazamiento
   Coordinate c0 = new Coordinate(g.Coordinates[0]);
   Coordinate c4 = new Coordinate(g.Coordinates[4]);
   //Instanciamos el filtro; puesto que queremos acceso a todo el array
   //de coordenadas de nuestra geometría, indicamos el tamaño del array
   CoordinateArrayFilter filter = new CoordinateArrayFilter(g.NumPoints);
   //El método Apply vuelca el array de coordenadas de la geometría en
   //el array de coordenadas del filtro
   g.Apply(filter);
   //Realizamos la operación de desplazamiento de vértices
   //sobre el array de coordenadas del filtro
   filter.Coordinates[0].X = c4.X;
   filter.Coordinates[0].Y = c4.Y;
   filter.Coordinates[4].X = c0.X;
   filter.Coordinates[4].Y = c0.Y;
   filter.Coordinates[5].X = c4.X;
   filter.Coordinates[5].Y = c4.Y;
   //Notificamos la actualización para que el Envelope pueda recalcularse
   g.GeometryChanged();
   Console.WriteLine(g.ToText());
   Console.Write("Press any key to continue . . . ");
   Console.ReadKey(true);
  }
 }
}

Si ejecutáis el código, obtendréis el siguiente resultado en WKT:

LINESTRING (100 110,  150 180,  200 210,
            210 140,  100 100,  100 110)

Y este sería el resultado gráfico:

¿Qué hay del modelo de precisión?

Lo cierto es que la clase CoordinateArrayFilter no toma en consideración el modelo de precisión de la geometría a modificar. Entonces ¿cómo podemos controlar que, ante un desplazamiento, las coordenadas se calculen sobre el “grid” de referencia asociado a la geometría? Una opción es utilizar la clase GeometryEditor, lo que implica generar una nueva geometría a partir de la antigua. Pero ya que hablamos de filtros y traslado de coordenadas, ¿por qué no derivar una clase de tipo ICoordinateFilter que, dado un desplazamiento (dx, dy), mueva una geometría al completo respetando su modelo de precisión? Aquí tenéis un ejemplo:

using System;
using GisSharpBlog.NetTopologySuite.Geometries;
using GisSharpBlog.NetTopologySuite.IO;

namespace CoordFilter
{
 class Program
 {
  public static void Main(string[] args)
  {
   string wkt = "LINESTRING (100.24 100.5, 150.82 180.56, 200.06 210.1, 210.44 140.82, 100.24 100.5)";
   //Asumiendo que la unidad principal es el metro, asociamos un "grid" centimétrico
   //a nuestro objeto GeometryFactory.
   WKTReader r = new WKTReader(new GeometryFactory(new PrecisionModel(100)));
   Geometry g = r.Read(wkt);
   //Instanciamos el filtro; puesto que queremos acceso a todo el array
   //de coordenadas de la geometría a desplazar, indicamos el tamaño del array;
   //además indicamos el modelo de precisión de dicha geometría.
   GeometryMoveFilter filter = new GeometryMoveFilter(g.NumPoints, g.Factory.PrecisionModel);
   g.Apply(filter);
   filter.Move(5.342237891, 3.865754133);
   g.GeometryChanged();
   Console.WriteLine(g.ToText());
   Console.Write("Press any key to continue . . . ");
   Console.ReadKey(true);
  }

  //Clase derivada de ICoordinateFilter para el desplazamiento
  //de geometrías acorde con un modelo de precisión. El código de esta
  //clase está basado en el de la clase CoordinateArrayFilter de NTS,
  //cuyo autor es Diego Guidi.
  class GeometryMoveFilter : ICoordinateFilter
  {
   Coordinate[] pts = null;
   int n = 0;
   PrecisionModel grid = null;

   //Al igual que la clase CoordinateArrayFilter, el constructor necesita
   //el tamaño del array de coordenadas. Adicionalmente se necesita el
   //objeto PrecisionModel que define el "grid" de referencia
   public GeometryMoveFilter(int size, PrecisionModel model)
   {
    pts = new Coordinate[size];
    grid = model;
   }

   //Este método aplica un desplazamiento en X y en Y sobre
   //cada coordenada
   public void Move(double xOffset, double yOffset)
   {
    for(int i = 0; i < n; i++)
    {
     Coordinate c = pts[i];
     //Aplicamos el desplazamiento
     c.X += xOffset;
     c.Y += yOffset;
     //Ajustamos la coordenada al "grid" de referencia
     grid.MakePrecise(ref c);
    }
   }

   public void Filter(Coordinate coord)
   {
    pts[n++] = coord;
   }
  }
 }
}

Si lo ejecutáis deberíais obtener el siguiente resultado:

LINESTRING (105.58 104.37, 156.16 184.43, 205.4 213.97, 215.78 144.69, 105.58 104.37)

Recordad que si estáis trabajando con NTS 1.2 hay que solucionar previamente un “bug” que afecta a la clase PrecisionModel. En este artículo encontraréis información sobre cómo resolverlo.

Cuando nos vemos en esta coyuntura, es decir, en la necesidad de transferir geometría entre aplicaciones mediante un formato interoperable pero de precisión limitada (i.e. DXF, WKT), hay que plantearse el uso de un modelo de precisión fija, a saber, un modelo que nos permita definir un “grid” al que siempre estarán referidas nuestras coordenadas, tanto las de origen como las derivadas del cálculo. En este breve artículo tenéis ejemplos de código fuente que os orientarán sobre cómo aplicar la clase PrecisionModel para trabajar con un “grid” de referencia en NetTopologySuite (NTS), el porting de JTS a C#, en su versión 1.2.

Definir un “grid” es sencillo. Basta con crear una instancia de la clase PrecisionModel y asignarlo al objeto GeometryFactory mediante el cual construyamos nuestras geometrías. Cada geometría así instanciada heredará una referencia a un “grid” que determinará cualquier cálculo en el que dicha geometría intervenga posteriormente. Pero, ¿cómo se especifica la precisión de dicho  “grid”? Asignando un factor de escala que equivale al denominador de la fracción deseada de la unidad principal. Por ejemplo, si la unidad principal es el metro asignaremos 100 para trabajar en centímetros (coordenadas con un máximo de 2 decimales), 1000 para trabajar en milímetros (coordenadas con un máximo de 3 decimales), 200 para trabajar con una precisión de 0.5 centímetros, …

using System;
using GisSharpBlog.NetTopologySuite.Geometries;

namespace Grids
{
 class Program
 {
  public static void Main(string[] args)
  {
   //Definición de varios "grids" asumiendo que trabajamos en metros
   PrecisionModel mGrid = new PrecisionModel(PrecisionModels.Fixed); //precisión métrica
   PrecisionModel mGrid2 = new PrecisionModel(1); //equivale al anterior
   PrecisionModel cmGrid = new PrecisionModel(100); //precisión centimétrica
   PrecisionModel mmGrid = new PrecisionModel(1000); //precisión milimétrica
   PrecisionModel halfcmGrid = new PrecisionModel(200); //0.5 cm de precisión
  }
 }
}

Cuando se parte de geometrías expresadas como WKT, la aplicación del “grid” a la imagen en memoria de las nuevas geometrías es transparente para el programador. Basta con asignar al objeto WKTReader el correspondiente objeto GeometryFactory. Esto significa que si probáis este código:

using System;
using GisSharpBlog.NetTopologySuite.Geometries;
using GisSharpBlog.NetTopologySuite.IO;

namespace Grids
{
 class Program
 {
  public static void Main(string[] args)
  {
   string wkt = "POLYGON ((253722.078898558 4292685.50730101, 253722.07889856 4292685.50730102, 253735.282733042 4292698.56531273, 253738.905778592 4292696.94218745, 253741.840165249 4292695.62758151, 253735.276565443 4292675.86615228, 253717.38 4292636.98, 253700.54 4292646.23, 253722.078898558 4292685.50730101))";
   PrecisionModel grid = new PrecisionModel(1000); //precisión milimétrica
   GeometryFactory gf = new GeometryFactory(grid); //vinculamos el "grid" con un objeto GeometryFactory
   WKTReader r = new WKTReader(gf); //asociamos el objeto GeometryFactory con el intérprete de WKT
   Console.WriteLine(r.Read(wkt).ToText()); //de WKT a Geometry y de nuevo a WKT
   Console.Write("Press any key to continue . . . ");
   Console.ReadKey(true);
  }
 }
}

Éste es el resultado que deberíais obtener:

POLYGON ((253722.079 4292685.507, 253722.079 4292685.507,
          253735.283 4292698.565, 253738.906 4292696.942,
          253741.84 4292695.628, 253735.277 4292675.866,
          253717.38 4292636.98, 253700.54 4292646.23,
          253722.079 4292685.507))

Sin embargo, puede ocurrir que nuestros datos de entrada se presenten como lista de pares (x,y). En este caso, el programador es responsable de hacer que cada coordenada se ajuste previamente a la precisión del “grid” de referencia. Esto se consigue de manera efectiva invocando al método MakePrecise del correspondiente objeto PrecisionModel. El siguiente ejemplo ilustra una solución para el polígono del ejemplo anterior, dada su lista de coordenadas.

using System;
using GisSharpBlog.NetTopologySuite.Geometries;
using GisSharpBlog.NetTopologySuite.IO;

namespace Grids
{
 class Program
 {
  public static void Main(string[] args)
  {
   List<double[]> coords = new List<double[]>();
   coords.Add(new double[]{253722.078898558, 4292685.50730101});
   coords.Add(new double[]{253722.07889856, 4292685.50730102});
   coords.Add(new double[]{253735.282733042, 4292698.56531273});
   coords.Add(new double[]{253738.905778592, 4292696.94218745});
   coords.Add(new double[]{253741.840165249, 4292695.62758151});
   coords.Add(new double[]{253735.276565443, 4292675.86615228});
   coords.Add(new double[]{253717.38, 4292636.98});
   coords.Add(new double[]{253700.54, 4292646.23});
   coords.Add(new double[]{253722.078898558, 4292685.50730101});

   PrecisionModel grid = new PrecisionModel(1000); //precisión milimétrica
   GeometryFactory gf = new GeometryFactory(grid); //vinculamos el "grid" con un objeto GeometryFactory
   Geometry g = GetPolygon(coords, gf); //instanciamos el polígono a partir de la lista de coordenadas y el objeto GeometryFactory
   Console.WriteLine(g.ToText()); //mostramos el resultado en WKT
   Console.Write("Press any key to continue . . . ");
   Console.ReadKey(true);
  }

  static Polygon GetPolygon(List<double[]> coords, GeometryFactory gf)
  {
   List<Coordinate> fixedCoords = new List<Coordinate>();
   foreach (double[] xyPair in coords)
   {
    fixedCoords.Add(GetFixedCoordinate(xyPair[0], xyPair[1], gf));
   }
   return gf.CreatePolygon(gf.CreateLinearRing(fixedCoords.ToArray()), null);
  }

  static Coordinate GetFixedCoordinate(double x, double y, GeometryFactory gf)
  {
   Coordinate c = new Coordinate(x, y);
   gf.PrecisionModel.MakePrecise(ref c); //cálculo de coordenada precisa, es decir, referida al "grid" del modelo de precisión milimétrica que lleva aparejado el objeto GeometryFactory
   return c;
  }
 }
}

Si ejecutáis este código deberíais obtener un resultado idéntico al anterior.

¿Y si no funciona …?

Como  dije al principio, podéis usar NTS 1.2 para probar estos ejemplos. Si preferís usar NTS 1.7 seguramente necesitaréis efectuar pequeños cambios en el código. De todos modos, tanto con la versión 1.2 como con la 1.7.1 hay un “bug” que hace que, independientemente del factor de escala, el modelo de precisión  fija quede referido siempre a la unidad principal, es decir, a coordenadas enteras. Este “bug” está corregido en la versión 1.7.3. Lo bueno de trabajar con software libre es que en la mayoría de casos (y éste es uno de ellos) la solución está a nuestro alcance. Así que, los que trabajéis con la versión 1.2, podéis descargar el código fuente aquí y modificar la línea 351 del fichero PrecisionModel.cs. Donde dice:

return Math.Floor(((val * scale) + 0.5d) / scale);

simplemente debe decir:

return Math.Floor((val * scale) + 0.5d) / scale;

Para aquellos que no conozcan R ( http://cran.r-project.org/ ), podemos decir que es un lenguaje de programación a la vez que un paquete estadístico de software, desarrollado bajo licencia GNU GPL de la Free Software Foundation. Lo más interesante de R es que se puede adaptar fácilmente a nuestros intereses mediante la instalación de nuevos paquetes. Hay muchos, y suelen englobar funciones comunes a una misma área de conocimiento. En nuestro caso, existen paquetes relacionados con el tratamiento de la información espacial y más directamente, otros que se relacionan con software GIS. Por poner algunos ejemplos, podemos interactuar desde el GUI de R con SAGA GIS, Grass6, GDAL… y utilizar muchas de sus herramientas, o bien trabajar con otros paquetes propios de R.

En este artículo no trabajaremos desde el GUI de R. Queremos mostrar como integrar R en nuestras aplicaciones de escritorio de .NET mediante objetos COM.

Para poder comenzar, deberemos instalar un servidor COM disponible en http://cran.r-project.org/. Entramos en la sección de software/otros/ e instalamos  R-(D)COM Interface. Por supuesto, también necesitamos tener instalado R 2.8.1. Por otra parte puede ser conveniente instalar un paquete de R llamado rcom con todas sus dependencias.

A partir de aquí, este artículo está dividido en tres partes por motivos didácticos. Primero se habla de cómo se trabaja con Rcom, después describimos cómo se usa el visor de histogramas (que es el ejemplo propuesto), y por último entramos en algunos detalles del código.

Para descargar el código fuente de R2csharp  podéis hacer un checkout del siguiente repositorio Subversion de GIS&Chips:

svn co http://www.gisandchips.org/svn/r2csharp

Uso básico de Rcom

Una vez instalado el servidor COM agregamos todas las referencias a un proyecto WindowsForm  en nuestro IDE de C# y sus correspondientes using (aquí hemos trabajado con Visual C# Express Edition).

using STATCONNECTORCLNTLib;
using StatConnectorCommonLib;
using STATCONNECTORSRVLib;

Con lo que podemos crear nuestro primer objeto de conexión a R, e iniciar una sesión

//Conexión a R
StatConnector sc1 = new STATCONNECTORSRVLib.StatConnectorClass();
sc1.Init("R");

A partir de aquí trabajaremos con tres métodos para interactuar con la sesión de R. Estos son:

• sc1.EvaluateNoReturn(“código de R”);

• sc1.Evaluate(“código de R”);

• sc1.GetSymbol(“nombre de un objeto de R”);

He observado que en ocasiones es indistinto el uso de las dos primeras, pero también podemos recibir una excepción en tiempo de ejecución, por lo que utilizaremos la primera para ejecutar código de R que no tiene porqué devolver ningún resultado (por ejemplo setwd(‘C:/’) , asigna el directorio de trabajo de R), mientras que el resultado de sc1.evaluate() habitualmente querremos almacenarlo en un objeto para poder consultarlo (no tiene sentido hacer un getwd() para después no mostrar su valor, sc1.Evaluate(“wd<-getwd()”), con esto almacenamos el wd en un objeto, el cual podemos consultar desde nuestra aplicación).

Por último, sc1.GetSymbol(“wd”) nos sirve para consultar un objeto creado en nuestra sesión de R y manipularlo. Por ejemplo, podríamos querer mostrar en una etiqueta lblWD la ruta del directorio de trabajo.

string wd = (string)sc1.GetSymbol("wd");
lblWD.Text = wd;

Hasta aquí ya hemos visto todo lo necesario para interactuar con R. Pero la complejidad puede ser mayor debido a las diferencias entre tipos de datos de R y de .NET. Mientras que en R hablamos entre otros de vectores, listas, matrices y dataframes (de números, caracteres…), en .NET tendremos arrays de distintos tipos o tipos simples. Deberemos consultar el tipo antes de almacenar los datos en estructuras de .NET. Esto lo podemos hacer mediante:

txtType.Text = sc1.GetSymbol("wd").GetType().ToString();

donde averiguamos que la función getwd() devuelve un string de .NET. Utilizaremos GetType() muy amenudo. Solamente hay que pensar que estructuras como un dataframe tendrán una estructura en .NET de array de arrays de… por lo que deberemos tener muy en cuenta los tipos de cada vector miembro del dataframe (podemos entender un dataframe como un conjunto de vectores relacionados; cada vector puede ser un campo de la “tabla” que es un dataframe).

R2csharp_histoviewer

Nuestra aplicación es algo más que un “!Hola mundo ¡ “. Tiene ejemplos básicos de distintas tareas habituales en R, pero en este caso realizadas desde nuestra aplicación. En esta demostración creamos un visor de histogramas con Windows Forms, que organiza la información de R de un modo claro y permite crear, mostrar, editar y eliminar dataframes de R, ejecutar una sencilla función de R (“hist( )“), y también crear y eliminar ficheros en el sistema operativo (imágenes, directorios…).

Podemos simular una sesión de trabajo con este visor siguiendo estos pasos (también vemos la correspondencia de las acciones en comandos de R):

1. Seleccionar cargar objeto para añadir uno a uno los tres ficheros de ejemplo ( bichos.txt, spatstat.txt y usos.txt)

read.table()

2. Seleccionar el objeto bichos y borrarlo

rm(bichos)

3. Seleccionar un campo en el segundo listbox y crear su histograma      presionando el botón Hist.

hist(objeto$campo) / nos ahorra hacer un attatch() en R

4. Editar una celda del campo “incendio” del objeto usos. Cambiar algún 0 por    100, y creamos de nuevo el histograma. Vemos como ha cambiado el objeto de R sin necesidad de conocer la posición del dato dentro del dataframe. (para   saber que estamos editando en el row del datagridview deberá verse un lapiz sobre el “row head”)

Vista de la aplicación en funcionamiento

Evidentemente, sin que el usuario lo sepa se están realizando varios list(), se aplican filtros, se obtienen los rownames() y colnames(), y otras operaciones habituales en R que aquí no se necesitará teclear y cuyos resultados estarán siempre visibles. Lo cual hace que nuestro interfaz sea más amigable solo por esto.

Algunas notas sobre el código:

Entre las tareas más interesantes en el código podemos ver un ejemplo de lectura y escritura de un dataframe en un datagridview, teniendo en cuenta los dos tipos de datos devueltos (enteros y dobles). El fichero de ejemplo spatstat.txt intercala columnas de datos dobles y enteros, claro que también podría haber String [] u otros, pero confiamos en que estas mejoras las puedan realizar nuestros lectores.

En el flujo de trabajo habitual hay dos tipos de objetos, los que contienen nuestros datos y los que utilizamos para interactuar con R. Estos últimos los ocultamos al usuario mediante condiciones “if”.

A la hora de crear imágenes temporales podemos hacer que se muestren en el device de R si no especificamos ningún dispositivo de salida para hist(). Aunque me ha parecido más interesante integrar la gráfica en el formulario. Para esto hay que decir que existe un problema al usar el portapapeles de Windows para almacenar un metafile, que es el único formato que R nos permite. Se trata de una incompatibilidad del SO que no nos permitirá recuperar la imagen del clipboard para mostrarla en el picbox (podemos consultar algo acerca de esta cuestión en http://support.microsoft.com/?scid=kb%3Ben-us%3B323530&x=11&y=12 ) Por este motivo, recurrimos a crear nuestro propio directorio temporal, el cual eliminamos al cerrar el formulario.

Hay que decir que Rcom aporta muchas posibilidades más directas para mostrar o trabajar con los datos de R. No obstante, considero que ya es mucho trabajo conocer un lenguaje de .NET y tener conocimientos de R, como para también especializarse en todas las opciones de Rcom. Para empezar está muy bien, pero en caso de trabajar a menudo con estas herramientas debería explorarse los ejemplos de Rcom, por si resultan más funcionales.

Una consideración que puedo transmitir a los lectores es que no existe ningún “binding” para C# /.NET que nos evite tener que embeber código de R en nuestra aplicación, así como existe rJava (http://cran.r-project.org/web/packages/rJava/index.html ). En caso de disponer de tal posibilidad la hubiésemos utilizado por múltiples motivos, sobretodo por el uso de un solo lenguaje de programación, lo que facilita la comprensión y sencillez del código y también la depuración de la aplicación.

No es necesario advertir que un buen conocimiento de R y las funciones que se quiera aplicar es fundamental para diseñar el mejor interfaz de usuario posible. Pero en determinados casos donde se debe efectuar análisis exploratorios de los datos el esfuerzo se verá compensado por la comodidad y la rapidez en el trabajo. Incluso pensándolo bien, en equipos de trabajo donde haya investigadores o técnicos que no dominen R la creación de un interfaz de este tipo puede ser más que interesante.

Algunas referencias:

En www.CodeProject.com existe un ejemplo de aplicación para C# (http://www.codeproject.com/KB/cs/RtoCSharp.aspx ) donde se repasan las posibilidades básicas para interactuar con R. También hay varios ejemplos de código disponibles para VB6 en la carpeta donde se nos instala el COM Server (por defecto “C:\Archivos de programa\R\(D)COM Server\samples”). Por último, la lista de distribución de Rcom donde se tratan muchas cuestiones relacionadas está en http://mailman.csd.univie.ac.at/pipermail/rcom-l/ .

Datos de ejemplo:

Descargar usos.txt

Descargar spatstat.txt

Descargar bichos.txt

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

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

Benito M. Zaragozí

benito.zaragozi@ua.es

svn co http://www.gisandchips.org/svn/gizmo/release_0.1

Obtendréis una solución SharpDevelop en C# con el proyecto del API Gizmo. El proyecto compila sobre el framework .NET 2.0 e incluye los ensamblados de referencia de Perst.NET, NetTopologySuite y ProjNET.

Cómo diseñar nuestro propio modelo

En pocas palabras, Gizmo es un conjunto de interfaces y clases que facilitan al desarrollador la definición de su propio modelo de objetos geográficos de forma que éstos puedan ser almacenados en una base de datos Perst. Como ya he dicho, esto no deja de ser un experimento: no esperéis una herramienta CASE o un interfaz amigable de diseño a base de diagramas. De momento se trata de que podáis definir vuestras clases siguiendo una lógica coherente de derivación e implementación de métodos y propiedades sin preocuparos excesivamente de cómo funciona Perst. Recordad que, al fin y al cabo, el objetivo es que podáis persistir/serializar en un fichero binario cada objeto geográfico que instanciéis, para poder recuperarlo más adelante mediante criterios espaciales gracias a los índices R-Tree. No hay tablas, ni campos, ni registros. No hay Object Relational Mapping. Se trata de vuestros propios objetos, tal y como los hayáis definido en vuestro modelo, con el estado en que se encontraban al serializarlos.
Pero veamos un ejemplo básico de aplicación en línea de comandos con C#. Para nuestro proyecto necesitaremos sendas referencias a Gizmo y Perst.NET. Para mayor comodidad incluid el proyecto de Gizmo en vuestra solución y añadidlo como referencia en vuestro proyecto de aplicación de consola. Respecto a Perst.NET, disponéis de una copia del ensamblado en el directorio lib del proyecto Gizmo (lib\Perst4.NET\PerstNetGenerics.dll) que podéis usar para agregarlo como referencia en vuestro proyecto.

Construiremos un modelo muy simple en el que vamos a representar parcelas y conducciones. Esta podría ser la definición de nuestra clase Parcela:

using System;
using Gizmo.Core;

namespace TestGizmo
{
 public class Parcela : GizmoObject
 {
  string _id = string.Empty;
  string _cultivo = string.Empty;

  public string Id {
   get { return _id; }
  }

  public string Cultivo {
   get { return _cultivo; }
  }

  public Parcela(string wkt, int srid,
                 string id, string cultivo) : base(wkt, srid)
  {
   _id = id;
   _cultivo = cultivo;
  }
 }
}

Y esta la definición de la clase Conduccion:

using System;
using Gizmo.Core;

namespace TestGizmo
{
 public class Conduccion : GizmoObject
 {
  string _id = string.Empty;
  string _categoria = string.Empty;

  public string Id {
   get { return _id; }
  }

  public string Categoria {
   get { return _categoria; }
  }

  public Conduccion(string wkt, int srid,
                    string id, string categoria) : base(wkt, srid)
  {
  _id = id;
  _categoria = categoria;
  }
 }
}

Ya tenemos la primera clave para implementar nuestro modelo con Gizmo: nuestros tipos de entidad geográfica deben derivar de la clase GizmoObject y pasar en el constructor dos parámetros comunes a cualquier objeto geográfico en Gizmo, a saber, la geometría (en nuestro caso en WKT) y el identificador del Sistema de Referencia espacial.

El siguiente paso es crear el catálogo de índices de nuestro modelo. Esto nos permitirá implementar búsquedas eficientes por atributos. Para ello definamos una clase Catalogo:

using System;
using Gizmo.Catalogue;
using Perst;

namespace TestGizmo
{
  public class Catalogo : GizmoCatalogue
  {
    FieldIndex<string, Parcela> _parcelaIdIdx = null;
    FieldIndex<string, Parcela> _parcelaCultIdx = null;
    FieldIndex<string, Conduccion> _conduccionIdIdx = null;
    FieldIndex<string, Conduccion> _conduccionCatIdx = null;

   public FieldIndex<string, Parcela> ParcelaIdIdx {
     get { return _parcelaIdIdx; }
   }

   public FieldIndex<string, Parcela> ParcelaCultIdx {
     get { return _parcelaCultIdx; }
   }

   public FieldIndex<string, Conduccion> ConduccionIdIdx {
     get { return _conduccionIdIdx; }
   }

   public FieldIndex<string, Conduccion> ConduccionCatIdx {
     get { return _conduccionCatIdx; }
   }

   public Catalogo(Storage db, string name) : base(db, name)
   {
     _parcelaIdIdx = db.CreateFieldIndex<string, Parcela>("Id", true);
     _parcelaCultIdx = db.CreateFieldIndex<string, Parcela>("Cultivo", false);
     _conduccionIdIdx = db.CreateFieldIndex<string, Conduccion>("Id", true);
     _conduccionCatIdx = db.CreateFieldIndex<string, Conduccion>("Categoria", false);
   }

   public Catalogo()
   {
   }
 }
}

Como podeis ver aquí la clave está en derivar de la clase GizmoCatalogue, crear en el constructor un índice simple de Perst para cada una de las propiedades de nuestras clases Parcela y Conduccion e implementar los getters correspondientes. Alguien se preguntará “¿y qué hay del índice espacial?”: bueno, precisamente de esa tarea se ocupan Gizmo y Perst en última instancia.

Finalicemos nuestro modelo agregando una clase layer para cada uno de nuestros tipos de entidad geográfica. Esta es la clase CapaParcelas:

using System;
using Gizmo.Core;

namespace TestGizmo
{
 public class CapaParcelas : GizmoLayer
 {
  public Catalogo _root = null;

  protected override Type CatalogueType
  {
   get { return typeof(Catalogo); }
  }

  protected override Type TargetType
  {
   get { return typeof(Parcela); }
  }

  public CapaParcelas(GizmoStore gs, string name) : base(gs, name)
  {
   this._root = (Catalogo) base.Root;
  }

  public Parcela FindById(string id)
  {
   return _root.ParcelaIdIdx.Get(id);
  }

  public Parcela[] FindByCultivo(string cultivo)
  {
   return _root.ParcelaCultIdx.Get(cultivo, cultivo);
  }
 }
}

Y aquí tenéis la clase CapaConducciones:

using System;
using Gizmo.Core;

namespace TestGizmo
{
 public class CapaConducciones : GizmoLayer
 {
  Catalogo _root = null;

  protected override Type CatalogueType
  {
   get { return typeof(Catalogo); }
  }

  protected override Type TargetType
  {
   get { return typeof(Conduccion); }
  }

  public CapaConducciones(GizmoStore gs, string name) : base(gs, name)
  {
   this._root = (Catalogo) base.Root;
  }

  public Conduccion FindById(string id)
  {
   return _root.ConduccionIdIdx.Get(id);
  }

  public Conduccion[] FindByCategoria(string categoria)
  {
   return _root.ConduccionCatIdx.Get(categoria, categoria);
  }
 }
}

Las clases layer son el mecanismo para explotar objetos geográficos del mismo tipo. La clave está en designar el tipo asociado mediante la propiedad TargetType e implementar métodos de recuperación de objetos (FindBy…) mediante los correspondientes índices del catálogo.

¡Hagamos una prueba!

Ya podemos editar la función Main de nuestra aplicación de consola. No olvidéis añadir el correspondiente  using Gizmo.Core; en la cabecera de vuestro fichero Program.cs. En primer lugar creamos nuestra base de datos geográfica (gizmo.dbs), la abrimos y creamos las capas de parcelas y conducciones.

GizmoStore gs = new GizmoStore("gizmo.dbs");
gs.Open();
CapaParcelas cp = new CapaParcelas(gs, "parcelas");
CapaConducciones cc = new CapaConducciones(gs, "conducciones");

A continuación almacenamos un par de parcelas y una conducción a partir de geometrías en WKT en el sistema de proyección UTM 30N ED50 (SRID = 23030).

string wktP0 = "POLYGON((10 10, 10 20, 20 20, 20 10, 10 10))";
string wktP1 = "POLYGON((30 30, 30 40, 40 40, 40 30, 30 30))";
cp.Add(new Parcela(wktP0, 23030, "P0", "CEREAL"));
cp.Add(new Parcela(wktP1, 23030, "P1", "FRUTAL"));
string wktC0 = "LINESTRING(5 5, 45 45)";
cc.Add(new Conduccion(wktC0, 23030, "C0", "PRIMARIA"));

Como podéis ver,  almacenamos/persistimos nuestras parcelas y conducciones a través de la layer correspondiente invocando el método Add. En la layer CapaParcelas tenemos la parcela P0 con cultivo de CEREAL y la P1 con cultivo de FRUTAL. Y en la layer CapaConducciones tenemos la tubería C0 de categoría PRIMARIA. Hasta aquí todo resulta bastante sencillo. Pero ¿y si queremos saber por qué parcelas pasa la tubería C0? Pues bien, esta es la respuesta en 2 líneas:

Conduccion c0 = cc.FindById("C0");
IGizmoObject[] query = cp.FindCrossedBy(c0);

Y si imprimimos las parcelas resultantes,

foreach (IGizmoObject p in query)
{
 Console.WriteLine((p as Parcela).Id);
}
gs.Close();

el resultado que debemos obtener es P0 y P1.

Por cierto: ¡no olvidéis cerrar vuestra base de datos! (línea de código 17).

Eso es todo. Espero que disfrutéis un rato con Gizmo. En futuros artículos comentaré más aspectos de este proyecto.

Lo que aquí os ofrecemos es una herramienta que, dada una determinada entidad PostgreSQL/PostGIS, permite explorar rápidamente cuál es la relación entre tamaño de imagen, extensión del mapa, degradación visual y tiempo de proceso para un máximo de 4 valores de tolerancia designados por el usuario. Se trata de una aplicación sencilla, escrita en C#, en la que el área de trabajo se divide en cuatro paneles. En cada panel podemos asignar una tolerancia, visualizar la geometría simplificada resultante, echar un vistazo a la sentencia SQL ejecutada en PostgreSQL y comprobar el tiempo de proceso transcurrido en realizar la transacción en el servidor y generar la imagen resultante en el cliente. Además, en todo momento conocemos cuál es la dimensión en píxeles de la imagen y el ancho del mapa. La instantánea inferior muestra una sesión de Simplify Workbench en la que se compara la geometría simplificada de los municipios de España procedentes de la Base de Datos de Líneas Límite a escala 1:1.000.000 del IDEE. Se puede observar cómo el tiempo de proceso del panel C es casi 4 veces menor que el del panel A, mientras que el impacto en la visualización es casi inapreciable. Por el contrario, la reducción del tiempo de proceso en el panel D conlleva una degradación visual que, para la resolución de la imagen, no es aceptable.

Geometría simplificada de los municipios de España en Simplify Workbench. Fuente de datos: IDEE

Podéis disponer del código fuente de Simplify Workbench bajo licencia GPL haciendo un checkout del siguiente repositorio Subversion de GIS&Chips:

svn co http://www.gisandchips.org/svn/simplifyworkbench

Para los que queráis probarlo de inmediato, tened en cuenta que los datos de conexión a PostgreSQL y entidad PostGIS se configuran en el fichero XML app.config que acompaña al ejecutable. Por defecto, os proporcionamos una conexión al servidor PostgreSQL de GIS & Chips para que podáis hacer tests con los municipios del IDEE. Si vais a realizar pruebas con vuestros propios datos tened en cuenta que la función de simplificación de PostGIS (simplify o st_simplify) no opera sobre geometrías en coordenadas geográficas (e.g. SRID = 4326), por lo que la aplicación no realizará el tratamiento esperado. Tampoco opera sobre entidades con sistema de referencia espacial indeterminado en la tabla geometry_columns (i.e. SRID = -1).

Si eres desarrollador y te vas a ‘zambullir’ en el código seguramente te interesará conocer que Simplify Workbench no es más que una extensión de SharpMap con un interfaz gráfico en Windows.Forms. Formalmente es una solución desarrollada en el IDE de código abierto SharpDevelop, escrita en C# sobre el framework 2.0 de .NET. Integra tres proyectos:  SharpMap (versión 0.9), SharpMapSimplifyExtension y Simplify.

Seguramente alguno de vosotros ya conozca SharpMap. Desde que Morten Nielsen, su creador, publicó allá por 2005-2006  este versátil renderizador de cartografía basado en GDI+, una pequeña revolución se ha producido en el ámbito de los clientes GIS libres sobre plataforma .NET y de hecho el proyecto no sólo continúa muy activo sino que ha conseguido integrar un equipo consolidado de desarrolladores en torno a un ecosistema de proyectos interrelacionados. El proyecto SharpMap de Simplify Workbench corresponde a los fuentes de la versión 0.9, la versión estable, aunque observaréis que el namespace SharpMap.Data.Providers incluye el proveedor de PostGIS (PostGIS.cs) y una referencia a Npgsql, la librería de acceso a datos de PostgreSQL en su versión 2.0.4.

El proyecto SharpMapSimplifyExtension consta de dos clases: PostGISSimplify y VectorSimplifiedLayer. La primera es una derivación de la clase SharpMap.Data.Providers.PostGIS que modifica el método GetGeometriesInView de forma que la sentencia SQL subyacente invoque la función simplify de PostGIS con la tolerancia de entrada. También añade un delegado que permite recuperar mediante un evento tanto la sentencia SQL final como el ancho del bounding box. La segunda deriva de la clase SharpMap.Layers.VectorLayer, sobrecarga el constructor para instanciar capas vectoriales especificando una tolerancia de simplificación y modifica el método Render. Con estas dos simples extensiones podemos definir  una capa vectorial que muestre geometría simplificada de PostGIS sin variar sustancialmente la lógica habitual de trabajo con SharpMap, tal y como se muestra en este ejemplo:

//
//
//
string cnstr = "Server=your.pgsql.server;Port=5432;User Id=user;Password=secret;Database=yourDB";
string tableName = "yourPolygons";
string geomFieldName = "geometry";
string oidFieldName = "oid";
//Instance of data provider for PostGIS simplified geometry
PostGISSimplify src = new PostGISSimplify(cnstr, tableName, geomFieldName, oidFieldName);
//Instance of vector layer to hold simplified PostGIS geometry
//Third parameter is an integer corresponding to tolerance in Douglas-Peucker vertex reduction algorithm
VectorSimplifiedLayer lyr = new VectorSimplifiedLayer("SIMPLIFIED_LAYER", src, 1000);
lyr.Style.EnableOutline = true;
lyr.Style.Fill = Brushes.Transparent;
//Map object, the layer container and rendering logic construct in SharpMap
Map m = new Map(new System.Drawing.Size(350, 275));
m.BackColor = Color.White;
m.Layers.Add(lyr);
//Zoom to extents internally invokes the modified GetGeometriesInView method in PostGISSimplify class
m.ZoomToExtents();
//Retrieve map image
System.Drawing.Image img = m.GetMap();
//

El proyecto Simplify incluye el formulario estructurado en cuatro paneles comentado más arriba y una clase de conveniencia, MapRenderer, que encapsula la lógica de lectura del fichero app.config, definición de layer, obtención de la imagen, recuperación de la sentencia SQL y cálculo del tiempo de proceso. En el directorio de este proyecto encontraréis también el fichero de solución de SharpDevelop (Simplify.sln).

Para terminar, y puesto que muchos de nosotros aquí en GIS & Chips somos fans del framework de código abierto Mono, os animamos a que probéis a compilar usando esta plataforma. Sabemos positivamente que SharpMap 0.9, con pequeñas modificaciones, es compilable sobre Mono. Creemos, aunque no lo hemos comprobado, que el código de Simplify Workbench también lo es. Si alguno lo consigue nos alegrará que nos lo comente.

¡Disfrutad con Simplify Workbench!