En este artículo os muestro la demo nº2 que consiste en la creación de triángulos texturales directamente desde una Geodatabase que diseño y creo previamente dentro del TFM. Pero más adelante añadiré algunos comentarios de las otras demos.

Triángulo textural

El TFM

Es interesante comentar que el TFM es una pequeña parte de otra investigación que estoy realizando en el contexto de la comarca de la Marina Baja (Alicante-España) y los datos que se muestra en las distintas demos son parte de un muestreo para entender mejor el potencial nutritivo de los suelos de la comarca.

El título del TFM es “Diseño de una base de datos geográfica orientada al estudio de los suelos”. Evidentemente, en el espacio de un TFM no cabía desarrollar toda la idea, que podría ser muy trabajosa para una sola persona, del mismo modo que aquí no cabe desarrollar todo el TFM ya que hay algunas partes que no tienen que ver con lo que queremos contar en G&C.

Si entráis en la página principal del la Web de demostraciones podéis leer un poco más sobre la intención y contenidos del TFM ( http://www.gisandchips.org/demos/suelosTFM/ ). Además en esta página se explican los detalles de la tecnología utilizada y del método de trabajo (PostgreSQL, PostGIS, R, pl/R…).

Considero que las demos 2 y 3 son más interesantes, puesto que la primera es solo una función de clasificación que cada uno podría hacer a su gusto, pero si a alguien le interesa la explicaré más adelante.

Página de la Demo

Los triángulos texturales

El estudio de los suelos es una disciplina tremendamente amplia, por lo que aquí nos limitaremos a dar, de un modo más breve, las explicaciones necesarias para entender los gráficos resultantes.

Los triángulos texturales son gráficos que facilitan la interpretación de la granulometría del suelo. Así pues, habitualmente la textura del suelo se puede representar en un diagrama ternario. En dicho diagrama ternario se emplean reglas trigonométricas para representar en el plano coordenadas tridimensionales que se refieren a distintas combinaciones de clases granulométricas (clases texturales) cuya suma es constante (100). Por último, las clases texturales son convenientes para representar a la textura del suelo en mapas ya que resulta más sencillo representar una variable que no tres, y su uso es bastante amplio en descripciones y clasificaciones del suelo.

A pesar de todas las ventajas de estos gráficos, aparece la dificultad de que existen gran número de triángulos texturales que permiten la clasificación de los suelos, lo que implica que en caso de querer incluir herramientas relacionadas en una BDGS (Geodatabase de suelos) se deba considerar tal variedad de criterios. En este caso se ha creado un gráfico de texturas según las especificaciones del USDA (1951) en castellano.

Pese a que existe cierta variedad de programas pensados para la elaboración de los triángulos de texturas parece interesante que una BDGS que almacene los datos de textura de suelos sea capaz de generar este tipo de gráficos. Además, los otros software suelen ser difíciles de encontrar y poco flexibles. Aquí podemos modificar nuestro gráfico a placer.

Página de resultados de la demo

Demostración  Triángulo Textural

En la propia página Web (http://www.gisandchips.org/demos/suelosTFM/paginas/demo_tritex1.php ) se explica como interactuar con la demo, seleccionando las muestras que se desee, si se desea etiquetar las muestras y con que símbolo se van a representar. Como se puede ver, los datos han sido previamente ordenados según una consulta espacial usando funciones de PostGIS, por lo que la gráfica que vamos a generar se ve enriquecida por esta posibilidad. A partir de los datos seleccionados se ejecuta una función escrita en pl/R que usa la librería “Plotrix” de R para generar un triángulo textural personalizado y guardarlo como un fichero PNG en el servidor. La función que se usa en este ejemplo puede ser personalizada en muchos sentidos para obtener otros triángulos texturales (hay decenas), en otros idiomas, clasificando los símbolos por algún atributo de la base de datos…

El uso de la función resulta muy sencillo,

SELECT  _plr_clasif_textural ( 'arenas' , 'limos' , 'arcilla' , 'submuestra' , 'simbolo' , 'etiquetas') ;

y a continuación podemos ver el código que hemos usado para crearla, y algunos comentarios:

-- Function: _plr_clasif_textural(text, text, text, text, text, text)
-- DROP FUNCTION _plr_clasif_textural(text, text, text, text, text, text);
CREATE OR REPLACE FUNCTION _plr_clasif_textural(text, text, text, text, text, text)
RETURNS text AS
$BODY$

# Cargamos las librerias necesarias
library(Cairo)
library(plotrix)
# Definimos la funcion
clasif.textural = function (soiltexture = NULL, at = seq(0.1, 0.9, by = 0.1),
axis.labels = c("% arena (entre 0,05 y 2 mm)", "% limo (entre 0,05 y 0,002 mm)", "% arcilla (menor de 0,002  mm)"),
tick.labels = list(l = seq(10, 90, by = 10), r = seq(10,
90, by = 10), b = seq(10, 90, by = 10)), show.names = TRUE,
show.lines = TRUE, col.names = "black", bg.names = par("bg"),
show.grid = TRUE, col.axis = "black", col.lines = "black",
col.grid = "gray", lty.grid = 3, show.legend = FALSE, label.points = FALSE,
point.labels = '', col.symbols = "blue", pch = par("pch"),
...)
{
par(xpd = TRUE)
plot(0.5, type = "n", axes = FALSE, xlim = c(0, 1), ylim = c(0,
1), main = NA, xlab = NA, ylab = NA)
triax.frame(at = at, axis.labels = axis.labels,
tick.labels = tick.labels, col.axis = col.axis, show.grid = show.grid,
col.grid = col.grid, lty.grid = lty.grid)
arrows(0.12, 0.41, 0.22, 0.57, length = 0.15)
arrows(0.78, 0.57, 0.88, 0.41, length = 0.15)
arrows(0.6, -0.1, 0.38, -0.1, length = 0.15)
if (show.lines) {
triax.segments <- function(h1, h3, t1, t3, col) {
segments(1 - h1 - h3/2, h3 * sin(pi/3), 1 - t1 -
t3/2, t3 * sin(pi/3), col = col)
}
h1 <- c(85, 70, 80, 52, 52, 50, 20, 8, 52, 45, 45, 65,
45, 20, 20)/100
h3 <- c(0, 0, 20, 20, 7, 0, 0, 12, 20, 27, 27, 35, 40,
27, 40)/100
t1 <- c(90, 85, 52, 52, 43, 23, 8, 0, 45, 0, 45, 45,
0, 20, 0)/100
t3 <- c(10, 15, 20, 7, 7, 27, 12, 12, 27, 27, 55, 35,
40, 40, 60)/100
triax.segments(h1, h3, t1, t3, col.lines)
}
if (show.names) {
xpos <- c(0.5, 0.7, 0.7, 0.73, 0.73, 0.5, 0.275, 0.275,
0.27, 0.27, 0.25, 0.135, 0.18, 0.07, 0.49, 0.72,
0.9)
ypos <- c(0.66, 0.49, 0.44, 0.36, 0.32, 0.35, 0.43, 0.39,
0.3, 0.26, 0.13, 0.072, 0.032, 0.024, 0.18, 0.15,
0.06) * sin(pi/3)
snames <- c("arcillosa", "arcillosa", "limosa", "franco arcillosa", "limosa",
"franco arcillosa", "arcillosa", "arenosa", "franco arcillosa", "arenosa",
"franco arenosa", "arenosa", "franca", "arenosa", "franca", "franco limosa",
"limosa")
boxed.labels(xpos, ypos, snames, border = FALSE, col = col.names,
cex=0.8, xpad = 0.5)
}
par(xpd = FALSE)
if (is.null(soiltexture))
return(NULL)
soilpoints <- triax.points(soiltexture, show.legend = show.legend,
label.points = label.points, point.labels = point.labels,
col.symbols = col.symbols, pch = pch, ...)
invisible(soilpoints)
}
# Definimos la imagen
CairoPNG("…/images/clasificacion_textural.png", width=500, height=560)
# Construimos las consultas
select = 'select '
arena = paste(arg1, ',', sep=' ');
limo = paste(arg2, ',', sep=' ');
arcilla = paste(arg3, ' ');
from = ' from '
tabla = arg4
selection = paste(select, arena, limo, arcilla, from, tabla, sep='');
selectgids = paste('select gid', from, tabla, sep='');
# Ejecutamos las consultas
texturas <- pg.spi.exec(selection)
gids<- pg.spi.exec(selectgids)
# Ejecutamos la funcion creada mas arriba
soiltex.return<-clasif.textural(texturas,
pch=arg5, point.labels = gids[,], label.points=arg6)
dev.off()
# Damos permisos de lectura
system('chmod go+r …/images/clasificacion_textural.png');
# Una comprobacion para asegurarnos de que se ha creado la grafica, pero no afecta para nada.
if (file.exists('…/images/clasificacion_textural.png')) {
print ('Grafico realizado. Se llama …/images/clasificacion_textural.png')};

$BODY$
LANGUAGE 'plr' VOLATILE
COST 100;
ALTER FUNCTION _plr_clasif_textural(text, text, text, text, text, text) OWNER TO postgres;

Algunas notas sobre todo esto:

(1) En el TFM se apunta que en breve aparecerá una librería creada por Julien Moeys ( https://r-forge.r-project.org/projects/soiltexture/ ) que hará innecesario tener que crear la función por nosotros mismos como hemos hecho en esta demostración. Será interesante comentar con los miembros del proyecto la posibilidad de compartir las funciones de su proyecto en una Web completamente dedicada al cálculo de triángulos texturales, donde los usuarios puedan añadir sus propios datos.

(2) Los datos de ejemplo están un poco modificados pero se aproximan a la realidad.

(3) La función tiene muchos aspectos mejorables, por lo menos en cuanto a la legibilidad. Otra posibilidad sería la de que no todos los argumentos de entrada fuesen de tipo texto. Esto lo veremos plasmado en el código de la demo 3.

(4) Si en la página  inicial de la demo no se ve una lista con las muestras disponibles (como en la segunda imagen) será porqué el servidor de la base de datos ha caído y lo deberemos reiniciar en breve. Solo ha pasado una vez, pero quien sabe…

(5) Este artículo destaca la potencia de pl/R a la hora de crear gráficos de lo más complejos.

Agradecimientos:

El TFM de que he estado hablando ha sido dirigido por Toni Hernández, en el Máster en Sistemas de Información Geográfica y Teledetección de la Universitat de Girona (UNIGIS), y fue presentado en Mayo de 2010. Les estoy muy agradecido a todos los miembros, tanto alumnos como profesores, por estos últimos años disfrutando y aprendiendo SIG.

Especialmente, quiero agradecer a los compañeros de G&C por la ayuda con instalaciones, creación de la Web y otros dolores de cabeza.

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

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

Benito M. Zaragozí

benito.zaragozi@ua.es

Planteado el problema, la primera solución que viene a la mente pasa por un “trigger” que haga la llamada a la correspondiente función de evaluación y lance un mensaje de error en caso necesario. Sin embargo, si lanzar el mensaje de error no es absolutamente necesario y lo que perseguimos es que una transacción de, por ejemplo, 1000 geometrías donde 50 son duplicadas, se complete con los 950 registros válidos insertados, entonces podemos usar una regla o RULE. Cada dos por tres estoy revisitando el sistema de reglas de PostgreSQL y no deja de sorprenderme por su versatilidad y elegancia. Echad un vistazo a la solución propuesta y decidid por vosotros mismos:

CREATE OR REPLACE RULE skip_duplicate AS
 ON INSERT TO table_name
 WHERE 0 != (SELECT count(*)
 FROM table_name
 WHERE geom_field ~= new.geom_field) DO INSTEAD NOTHING;

Como podéis comprobar, hay 2 claves para interpretar esta regla:

1) Es una regla condicional (CREATE RULE … WHERE … DO …), y en la condición integramos una subquery que emplea el operador de igualdad geométrica (~=) para evaluar si la geometría de entrada (new.geom_field) es un duplicado. Recordad que, para acelerar el proceso, los operadores de PostGIS explotan, si está presente, el índice GIST sobre el campo de geometría.

2) Con INSTEAD NOTHING indicamos al motor de reescritura de expresiones subyacente al sistema de reglas que, cuando se cumpla la condición anterior, simplemente vacíe la expresión entrante y no haga nada. Por tanto, la sentencia INSERT se omite y deja de formar parte de la transacción actual.

¡Eso es todo!

Para ello una simple ojeada a la documentación de POSTGIS y encontré la función que necesitaba, st_union. Esta función nos une la geometría en función de un atributo seleccionado.

Voy a mostrar un ejemplo sencillo, pero muy pedagógico.  En este ejemplo partimos de tres polígonos simples,  su geometría es de tipo POLYGON y quiero unirlos por un atributo común, en su caso el código.

Vemos en la imagen anterior los 3 polígonos, dos de los cuales tienen el mismo atributo (campo código).

La SQL quedaría de la siguiente manera:

select st_union(geometria) from poligonos group by codigo;

El problema viene con el resultado de esa consulta, y es la heterogeneidad del tipo de geometría:

Para que eso no ocurra, añadimos la función st_multi, y conseguimos una homogeneidad del tipo de geometría, convirtiendo todas las geometrías en MULTIPOLYGON:

select st_multi(st_union(geometria)) from poligonos group by codigo;

En caso de que los polígonos sean adyacentes, pasaría a ser un único polígono, es decir,  elimina la frontera entre ambos.

Ahora comprobamos que al usar st_union, simplemente nos ha creado un polígono a partir de un atributo común, manteniendo la geometría de tipo POLYGON y en este caso ya no hace falta usar st_multi.

Obviaremos la construcción del mapfile, ya que fue abordado en otro artículo, pero trabajaremos a partir de ese código.

Lo primero que necesitamos hacer es preparar la función en lenguaje PL/pgSQL que nos devolverá las coordenadas de los vértices que componen cada uno de los polígonos a partir de un parámetro, que en nuestro caso será el código municipal, y posteriormente se hará la conversión de esos vértices de metros a pixel con PHP.

CREATE OR REPLACE FUNCTION gc_listvertices(cod_municipal character varying)
RETURNS SETOF record AS
$BODY$
DECLARE
countpol bigint;
polygon geometry;
perimeter geometry;
countpoints integer;
i integer;
j integer;
point record;
BEGIN
--Teniendo en cuenta que cada municipio puede estar compuesto de varios polígonos, primero hacemos un conteo de los polígonos de cada municipio
select into countpol count(*) from (select st_dump(geometria) from municipios where codmun= cod_municipal) foo;
for j in 1..countpol loop
--Por cada municipio, nos devolverá los polígonos descompuestos. La función st_dump, lo que nos devuelve es tantas filas como polígonos contiene el municipio en cuestión, es decir nos descompone el MULTIPOLYGON en un array que contiene un único POLYGON
select into polygon geom from (select (st_dump(geometria)).path, (st_dump(geometria)).geom from municipios where codmun = cod_municipal) foo where path[1] = j;
--La función st_exteriorring nos devuelve un LINESTRING, que representa el anillo exterior del polígono dado.
--ATENCIÓN: esta función no trabaja con MULTIPOLYGON, de ahí la descomposición anterior
select into perimeter st_exteriorring(polygon);
--Contamos el número de vértices que componen el POLYGON
select into countpoints st_npoints(polygon);
for i in 1..countpoints loop
--Por último, nos guardamos en una variable, la coordenada X y la coordenada Y de cada vértice.
--ATENCIÓN: puesto que nos devuelve indiscriminadamente las coordenadas de todos los vértices de todos los polígonos que componen el municipio, se ha añadido un campo booleano que nos devuelve true en caso de ser un vértice final.
select into point st_x(st_pointn(perimeter, i)), st_y(st_pointn(perimeter, i)), (i=countpoints) as tend;
return next point;
end loop;
end loop;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE
COST 100
ROWS 1000;
ALTER FUNCTION gc_listvertices(character varying) OWNER TO postgres;

Ahora sólo queda hacer la conversión con PHP:

<?php header('Content-Type: text/html; charset=UTF-8'); ?>
<html>
<head>
<title>Ejemplo de mapa sensible</title>
<style type="text/css">
.munInfo{
border: 1px solid #C0C0C0;
background-color: white;
border-bottom-width: 0;
width: 170px;
height: 70px;
position: absolute;
}
</style>

<script>
function info(nombre,area)
{
        document.getElementById('munInfo').innerHTML = "Municipio="  + nombre +" <br> Area =" + area +" km2";
}
</script>
</head>
<body>
<?php
//Este código es el usado en un artículo anterior, pero para hacer más fluido el ejemplo, sólo se han seleccionado los municipios de la Comunidad Valenciana. Lo ideal es automatizar tanto la extensión máxima de la caja de la geometría como su equivalencia en el tamaño en pixeles del mapa. Para hacer el ejemplo más fluido se añaden estos parámetros a mano.
dl('php_mapscript.so');
$Map=ms_newMapObj("");
$Map->set("name","Mapa");
//Equivalencia en pixeles del tamaño del mapa
$Map->setSize(432,750);
//Extensión de la caja para los municipios de la Comunidad Valenciana
$Map->setExtent(626680,4191059,815673.125,4519371);
$Map->web->set("imagepath","/tmp");
$Map->web->set("imageurl","/ms_tmp");
$Layer2=ms_newLayerObj($Map);
$Layer2->set("name","Municipios");
$Layer2->set("type",MS_LAYER_POLYGON);
$status = $Layer2->set("status",MS_ON);
$Layer2->setConnectionType(MS_POSTGIS);
$Layer2->set("connection","user=****** dbname=demos host=localhost");
//La consulta ha sido modificada con respecto a la original, para mostrar sólo los municipios de la Comunidad Valenciana
$Layer2->set("data","geometria from (select geometria,gid from  ine.municipios where com = '10') as foo  using unique gid using srid=23030");
$clase = ms_newClassObj($Layer2);
$estilo = ms_newStyleObj($clase);
$estilo->color->setRGB(217,233,107);
$estilo->outlinecolor->setRGB(0,0,0);
$Image=$Map->Draw();
$url_imagen=$Image->saveWebImage();
//Añadimos que la imagen será usada como un mapa de html
echo "<img src=".$url_imagen." usemap='#sensible'>";
echo "<map name='sensible'>";

//Lo siguiente, es conectarse a la base de datos para consultar los municipios que vamos a mostrar en el mapa
$conn = pg_connect("host=localhost port=5432 dbname=demos user=****** password=******");
$sqlmun= "select nombre04 as nombre,codmun as codmunicipal, area(geometria) as area from ine.municipios where com = '10'";
$poligono = pg_query($conn,$sqlmun);
$rowspol=pg_num_rows($poligono);
for ($h=0; $h<$rowspol; $h++)
{
        $arraypol=pg_fetch_array($poligono,$h);
        $nombre=$arraypol['nombre'];
        $codmun=$arraypol['codmunicipal'];
        $area=round(($arraypol['area']/1000000),2);

        $pxmin = 626680;
        $pymin = 4191059;
        $pxmax = 815673.125;
        $pymax = 4519371;

        //distancia en metros de los ejes
        $eqx=$pxmax-$pxmin;
        $eqy=$pymax-$pymin;
//Llegados a este punto ejecutamos la función anterior que creamos en la base de datos, para que nos devuelva las coordenadas de los vértices de cada uno de los polígonos
        $sqlpolcoords="select * from ine.gc_listvertices('$codmun') as foo(x float, y float,tend boolean)";
        $polcoords= pg_query($conn,$sqlpolcoords);
        $rowspolcoords=pg_num_rows($polcoords);
        for ($j=0; $j<$rowspolcoords; $j++)
        {
//Obtenemos los tres parámetros por separado que nos devuelve la función y hacemos la conversión de metros a pixel. Como he comentado anteriormente lo ideal es que esto se realice de manera automatizada, sin que introduzcamos nosotros la anchura y la altura del mapa
                $arraypolcoords=pg_fetch_array($polcoords,$j);
                $x=$arraypolcoords['x'];
                $y=$arraypolcoords['y'];
                $tend=$arraypolcoords['tend'];
                $xcal=$x-$pxmin;
                $ycal=$pymax-$y;

                $resx=round(((432*$xcal)/$eqx),0);
                $resy=round(((750*$ycal)/$eqy),0);
                $coordenadas.=$resx.",".$resy.",";
//Lo que va a hacer este parámetro es cortar cada polígono cada vez que devuelva true, de manera que en el caso de Alicante que son cuatro polígonos, los separa cada uno en un área distinta
                if($tend=='t')
                {
                        echo"<area shape=poly coords='$coordenadas' href=\"javascript:void(0);\" onClick=\"munInfo('$nombre','$area');\" alt='$nombre'>\n";
//Para el ejemplo he creado una simple función en javascript que nos muestre el nombre y el área en un div cuando pasemos el ratón por encima de cualquier municipio.
                        $coordenadas="";
                }
        }
}
echo"</map>";
?>
<div id="munInfo" class="munInfo"></div>
</body>
</html>

El resultado del ejemplo será este mapa sensible.

Resultado esperado:

El código de generación del mapfile será el mismo que en el  post de creación del mapfile “al vuelo”, tan solo habría que cambiar la forma de obtener los datos, para que en lugar de obtenerlos con una simple sentencia sql, llamar a una función que obtuviera las geometrías simplificadas a costa de perder nivel de detalle (inapreciable a la vista).

Cuando se trata de simplificar geometrías hay que tener en cuenta la dimensión del mapa que queremos obtener para en función de esta dimensión, poder obtener de alguna forma un coeficiente de simplificación que se adecue a la simplificación que pretendemos obtener (es decir, ni que no nos haga casi simplificación, ni que simplifique demasiado).

Para obtener este factor de simplificación, podemos hacer varias operaciones, en este caso realizaremos una operación como la siguiente, dividiremos el resultado de restar a la xmax la xmin de la entensión de la geometria entre el ancho del mapa que queremos obtener.

Es decir, obtenemos la extensión de la geometría que estamos analizando , sacamos al xmax y la xmin, las restamos y el resultado lo dividimos entre el ancho del mapa que queremos obtener:

(xmax(extent(geometria) )- xmin(extent(geometria)))/Ancho del mapa

Creamos una función en sql para obtener el factor de simplificación que deseamos:

create or replace function fs(float8) returns float8 AS $$
 select (xmax(extent(geometria))-xmin(extent(geometria)))/$1 from ine.municipios;
$$ LANGUAGE SQL;

Una vez que tenemos el factor de simplificación obtenido con la función anterior, ya podemos aplicar la simplificación con el factor de simplificación obtenido anteriormente.

Podemos hacer una comparativa del aumento de velocidad entre realizar una consulta sin simplificación y otra con la simplificación, por ejemplo para un mapa bastante grande de 4000px.

1ª consulta: “select geometria  from municipios2”

2ª consulta:”select st_simplify(geometria,factor_simplificacion) from municipios2”

En PostgreSQL, al ejecutar las dos sentencias podemos comparar y obtener:

1ª consulta

• Tiempo de ejecución de la consulta: 50,84 segundos
• Numero de vertices: 393666

2ª consulta

• Tiempo de ejecución de la consulta: 19,51 segundos
• Numero de vertices: 141610

De esta manera comprobamos que se produce un aumento en la velocidad a cambio de reducir el nivel de detalle, circunstancia que nos viene bien de cara a la publicación web, ya que no necesitamos un nivel de detalle elevado.

Para constaruir ahora la layer en MapScript, la sentencia SQL para obtener los datos sería como esta:

$name = $Layer2->set("name","Municipios");
$type = $Layer2->set("type",MS_LAYER_POLYGON);
$status = $Layer2->set("status",MS_ON);
//Conexión con nuestra base de datos que va as er de tipo POSTGIS
$Layer2->setConnectionType(MS_POSTGIS);
//Cadena de conexión a la base de datos donde tenemos nuestros datos

//En primer lugar, debemos obtener el factor de simplificación que obtenemos mediante consulta a postgresql desde php:
$conexion = pg_pconnect("host=localhost port=5432 dbname=demos user=postgres");

$sql="select fs(".$Map->width.")";
$resultado=pg_exec($conexion,$sql);
$factor=pg_result($resultado,0,0);

$Layer2->set("connection","user=postgres dbname=demos host=localhost");
//Filtro en sql que vamos a introducir para sacar nuestros datos a mostrar, aplicando el factor obtenido anteriormente
$data="geometria from (select st_simplify(geometria,".$factor.") as geometria, nombre,provincia,gid from municipios) as foo using SRID=23030, using unique gid";
$Layer2->set("data",$data);
//Una vez definida la estructura d ela capa procedemos a definir el estilo de nuestra capa número 1

Para la comparación de velocidad de creación de un mapfile con una única capa PostGIS utilizando una sentencia SQL normal y utilizando simplificación de geometrías, utilizando para ello varios test de medición de velocidad de carga, asumimos que vamos a crear un mapa bastante grande de una dimensión de 2000×2000 pixeles.

Sin simplificación de geometrías (tal y como se hizo en el artículo anterior, pero con una sola capa y de tamaño 2000×2000 píxeles)

Con simplificación de geometrías (utilizando la función que hemos programado anteriormente)

Para realizar la comparativa de cargas he utilizado la herramienta Speed-Test

El resultado que he obtenido es el siguiente:
(no se aprecia mucha diferencia, pero es debido a que se ha guardado en la caché y no es significativa la diferencia)
- Con la sentencia normal (sin simplificación)

- Utilizando el factor de simplificación y realizando una simplificación de las geometrías:

Lo que vamos a intentar conseguir es mostrar en una página web un fichero de mapa sin la necesidad de tener un fichero .map (MapFile) asociado y complejo de mantener, simplemente realizando modificaciones en nuestro código php.

Este es el resultado que queremos obtener:

Mapa de españa

Vamos a ponernos manos a la obra para conseguirlo.

En primer lugar, doy por supuesto que tenemos instalado MapServer y MapScript en nuestro servidor Linux (en mi caso CentOS)  y el Servidor de Bases de Datos PostgreSQL+PostGIS y con la extensión PHP/pgSQL.

Creamos un fichero .php

Lo primero que debemos hacer es cargar la librería PHPMapScript (php_mapscript.so)

dl('php_mapscript.so');

//Una vez cargada la librería ya se puede trabajar con las funciones propias de PHPMapScript
//Para empezar hay que crear el fichero mapa y definir las diferentes características que queremos que tenga el mapa (nombre, tamaño,

//Creamos un objeto llamado Map mediante el Constructor de MapObject

$Map=ms_newMapObj("");

//Le damos un nombre (p.e. mapa)
$Map->set("name","Mapa");

//La dimensión del mapa
$Map->setSize(600,600);

// La extensión del mapa (la podemos obtener de postgresql mediante la función de postgis st_extent
$Map->setExtent(626679.9375,4191059,815673.125,4519371);

// Se define el path de la imagen la temporal y la real que se mostrarán por web
$Map->web->set("imagepath","/tmp");
$Map->web->set("imageurl","/ms_tmp");

Una vez hemos definido las características de nuestro fichero de mapa, procedemos a incluir capas.
<pre>//Definimos una capa asociada a nuestro fichero de mapa anteriormente definido
// En este caso la primera capa, y que va a servir de fondo de nuestro mapa va a ser wms
// y del servicio wms que proporciona el <a href="http://www.idee.es/wms/PNOA/PNOA?Request=GetCapabilities&Service=WMS" target="_blank">PNOA</a></pre>
$Layer1=ms_newLayerObj($Map);

$Layer1->set("name","ortofoto");

//Tipo Raster

$Layer1->set("type",MS_LAYER_RASTER);

$Layer1->set("status",MS_ON);//El status de la Layer, esto nos permitirá definir layers y mantenerlas ocultas dependiendo de las necesidades que tengamos
$Layer1->setConnectionType(MS_WMS);
$Layer1->set("connection","http://www.idee.es/wms/PNOA/PNOA?");
//Definimos la proyección del wms junto con el nombre de la capa wms, la versión del servidor y el formato de la imagen
<pre>//El que esta capa se muestre o no, no depende de nosotros, depende de una fuente externa que proporciona la capa WMS, en este caso es la del PNOA</pre>
$Layer1->setProjection("init=epsg:23030");
$Layer1->setMetadata("wms_name","pnoa");
$Layer1->setMetadata("wms_server_version","1.1.1");
$Layer1->setMetadata("wms_format","image/png");

//Como segunda capa asociada a nuestro fichero de mapa anteriormente definido vamos a añadir una capa obtenida de nuestros datos en postgresql
$Layer2=ms_newLayerObj($Map);

//Vamos definiendo las características que va a tener esta nuestra primera capa
$name = $Layer2->set("name","Municipios");
$type = $Layer2->set("type",MS_LAYER_POLYGON);
$status = $Layer2->set("status",MS_ON);
//Conexión con nuestra base de datos que va as er de tipo POSTGIS
$Layer2->setConnectionType(MS_POSTGIS);
//Cadena de conexión a la base de datos donde tenemos nuestros datos
$Layer2->set("connection","user=postgres dbname=demos host=localhost");
//Filtro en sql que vamos a introducir para sacar nuestros datos a mostrar
// MUY IMPORTANTE es necesario incluir el unique gid y using srid=23030, si no no funcionará
$Layer2->set("data","geometria from ine.municipios using unique gid using srid=23030" );
//Una vez definida la estructura d ela capa procedemos a definir el estilo de nuestra capa número 1

$clase = ms_newClassObj($Layer2); //Definimos la clase
$estilo = ms_newStyleObj($clase); //El estilo asociado a dicha clase
$estilo->color->setRGB(10,150,190); //Los colores
$estilo->outlinecolor->setRGB(0,0,0); //El contorno

//Una vez hemos definido las capas tenemos que indicar que se dibuje el mapa
$Image=$Map->Draw();

//Muy importante que no se nos olviden estas 2 sentencias que vienen a continuación, si no ponemos que se almacene la imagen en el path que le hemos incluido o no la mostramos por pantalla con un echo, no va a mostarse nada, y caeremos en el desanimo ya que después de definir todo correctamente la página aparece en blanco.

$url_imagen=$Image->saveWebImage();
echo "<img src=".$url_imagen.">";

Y después de tener esto, solo hay que lanzar el navegador y et voilà!, tenemos nuestro primer mapfile utilizando PHPMapScript en nuestro navegador, puede que sea un poco lento a la hora de cargar, pero no depende tanto de nuestra capa en PostGIS sino del Servidor WMS que utilicemos como capa de fondo, que ya no depende de nosotros.

El resultado es este: http://www.gisandchips.org/demos/mapscript/index.php

]]> http://www.gisandchips.org/2009/11/02/creacion-de-un-mapfile-de-forma-dinamica-al-vuelo/feed/ 5 http://www.gisandchips.org/2009/04/29/simplify-workbench-banco-de-pruebas-para-geometria-simplificada/ http://www.gisandchips.org/2009/04/29/simplify-workbench-banco-de-pruebas-para-geometria-simplificada/#comments Wed, 29 Apr 2009 09:40:18 +0000 josetomas http://www.gisandchips.org/wordpress/?p=22 Optimizar nuestro cliente GIS, tanto para web como para escritorio, implica entre otras cosas afinar al máximo los rangos de escala de visualización para cada una de nuestras capas. Sin embargo puede darse el caso de que este mecanismo no sea aplicable. Ante esta situación, es importante que no renunciemos al ahorro en los tiempos de proceso, y en este sentido puede ser útil recurrir a la simplificación o generalización de la geometría.

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!