PDF de programación - Del SIG de escritorio al entorno cliente-servidor con Web Processing Service

Del SIG de escritorio al entorno cliente-
servidor con Web Processing Service

1 Centre de Recerca Ecològica i Aplicacions Forestals (CREAF)

Universitat Autònoma de Barcelona (UAB)

J. Masó1, Xavier Pons2,1

Bellaterra (Barcelona)
{joan.maso}@uab.es



2 Departament de Geografia

Universitat Autònoma de Barcelona (UAB)

Bellaterra (Barcelona)
{xavier.pons}@uab.es

Resumen

Esta ponencia discute algunas de las posibles arquitecturas que puede
presentar un servicio WPS a partir de un conjunto de módulos
disponibles en un SIG de escritorio. Se discute una arquitectura
centrada en servidor como las usadas en la nueva web 2.0 y una
arquitectura donde el servidor es un mero ejecutador de procesos
basados en datos remotos. Cada arquitectura necesita de distintos
elementos adicionales que no se describen en el propio estándar WPS,
que son identificados y para los cuales se proponen soluciones.

Palabras clave: Proceso, estándar, servicio, OGC, WPS.



1 Introducción

La aplicación de protocolos estandarizados en los portales de cartografía en
Internet ha permitido el acceso a usuarios de todo tipo y formación a la
visualización y consulta de cartografía de referencia y temática. Sin embargo, el
usuario experto, cuando trabaja en entornos web, echa en falta herramientas que le
permitan procesar los datos disponibles, cruzarlos y obtener resultados que puedan



ser de ayuda a la toma de decisiones. La mayoría de estas herramientas requieren
de la ejecución de procesos.
El estándar Web Processing Service (WPS) permite definir una interfaz
estandarizada por el Open Geospatial Consortium (OGC) para la ejecución de
procesos en un entorno cliente-servidor [4]. Estos procesos pueden ser, por
ejemplo, algoritmos de análisis, cálculos geodésicos de cambio de sistema de
referencia, modelos estadísticos aplicados a prospectiva territorial, etc, que son
funcionalidades típicas de los verdaderos SIG de escritorio. Por ello parece
indicado sugerir la extensión de las funcionalidades de un SIG de escritorio a un
entorno cliente- servidor usando WPS. En su primera versión, aprobada en 2007,
este estándar permite identificar los datos georeferenciados origen, iniciar el
proceso, controlar el estado de ejecución del mismo y entregar o identificar los
datos de salida.

El estándar deja totalmente abierto el origen de los datos pudiendo, pues, ser
diverso: los datos se encuentran en el propio servidor, los datos son accesibles
desde un servidor Web Feature Service (WFS) o Web Coverage Service (WCS), los
datos pueden extraerse de una geodatabase, los datos están embebidos en la propia
petición de ejecución como una colección de objetos Geography Markup Language
(GML) o los datos están en el cliente y este debe enviarlos al servidor con
anterioridad. Igualmente, este estándar WPS deja totalmente abierto el método a
seguir para devolver los resultados de la ejecución al servidor pudiendo ser:
almacenado en el propio servidor, mostrado al usuario a través de un servicio de
generación de representaciones pictóricas y posterior entrega mediante Web Map
Service (WMS) [1] , ofrecido a través de un servicio de descarga (WFS, WCS, ftp),
transferido a un servidor WFS transaccional, entregado como un conjunto de
objetos GML [2] embebidos en la respuesta de la ejecución, o listados para su
descarga posterior [3].

Por ello, un entorno que permita la ejecución de procesos WPS puede tener
diversas arquitecturas en función de los objetivos del mismo. Esta ponencia plantea
dos posibles arquitecturas a las que pueden optar los desarrolladores de programas
SIG de escritorio que ya dispongan de una colección de algoritmos, procesos y
módulos de calidad, para trabajar con información geográfica para desarrollar un
servicio WPS. Las dos soluciones son analizadas desde el punto de vista del
usuario, desde el punto de vista del rendimiento y desde el punto de vista de la
dificultad de implementación. Por supuesto existen otras aproximaciones posibles,
pero requieren de la participación de otros geoservicios, quedando más lejos del
software de escritorio, que es el punto de partida de esta comunicación.



La primera arquitectura estudiada realiza una aproximación centrada en el servidor,
siendo éste el almacén y el procesador, y limitando el uso del cliente a un simple
visualizador de vistas de la información. Esta aproximación está muy de moda en
el mundo de los nuevos servicios Web 2.0, donde servidores como Flickr permiten
al usuario mantener en el centro de datos (datacenter) del servicio toda la
información (en este caso fotografías) y, desde este, manipularla (procesos),
clasificarla, documentarla (metadatos, en el fondo) y compartirla. Llamaremos a
esta aproximación WPS-W2

La segunda aproximación mantiene la información en el cliente, por lo que el
servidor es meramente una herramienta para la realización del proceso. Esta
aproximación se parece más a la arquitectura del SIG de escritorio que puede tomar
datos de diferentes ubicaciones a partir de la red local, procesarlos en la CPU del
ordenador local y reenviarlos a un disco local o de red, sólo que en este caso la
perspectiva se invierte y es el servidor WPS remoto el que tiene la capacidad de
tomar datos de otras ubicaciones. Ni que decir tiene que esta aproximación requiere
de un mayor ancho de banda en el tráfico de redes respecto a la primera
aproximación. Llamaremos a esta aproximación WPS-R

2 Servidor de procesos en web WPS-W2

Las arquitecturas Web 2.0 se basan en el poder de la interacción con el usuario
como fuente de nuevos datos. Estos datos se almacenan en grandes centros de datos
de ubicación desconocida, e inaccesibles directamente por el usuario. El usuario
debe utilizar los recursos que el servicio le aporta o transferir sus datos al sistema
con anterioridad a cualquier acción. Esto simplifica la arquitectura WPS dado que
el usuario dispone de un catálogo de capas con las que trabajar que será idéntico
sea cual sea la ubicación de dicho usuario. De igual manera, el resultado de una
ejecución será almacenado en el propio centro de datos. El sistema dispondrá de
mecanismos para la visualización del resultado de la ejecución del proceso y,
eventualmente, para la exportación del resultado.

Para la ejecución del proceso, el usuario deberá seleccionar las capas implicadas de
entre las disponibles en el catálogo del servicio y posiblemente completar algunos
metadatos de la nueva capa generada. Una vez solicitado el inicio del proceso, el
servicio lo ejecutará e incluirá el resultado en el catálogo una vez acabado el
proceso. Sólo entonces el usuario podrá ver el resultado si lo desea.



PPrroottooccoolloo

WWPPSS

CCeennttrroo
ddee ddaattooss

PPrroottooccoolloo

WWPPSS

DDaattooss
SSIIGG

Figura 1. Arquitectura WPS-W2



3 Servidor de procesos remoto WPS-R

Para que sea posible el uso de WPS-R es necesario que exista una interfaz de
usuario en el lado cliente, un mecanismo para la transmisión de documentos
cartográficos (en adelante capas, para simplificar) del cliente al servidor, una
comunicación con el servidor para iniciar el proceso (junto con la información de
los parámetros de entrada), un mecanismo para informar al usuario del estado del
proceso y, finalmente, un sistema para transmitir al usuario el resultado del
proceso, que generalmente será una capa pero puede ser una tabla o un solo valor.
A continuación vamos a detallar cada uno de estos pasos.

La interfaz de usuario puede ser la misma usada por el programa de escritorio con
la salvedad de que debe indicarse qué servidor debe realizar la operación. El



mecanismo de transmisión de capas del cliente al servidor puede no ser un tema de
fácil solución para la mayoría de SIGs de escritorio dado que una capa puede estar
formada por un gran número de archivos interrelacionados, o incluso una estructura
de registros en varias tablas de una base de datos. Solamente algunos programas
SIG disponen de mecanismos para la transmisión de una capa o un proyecto
cartográfico en un solo archivo: ArcInfo dispone del formato de archivos export
(e00), MiraMon dispone del formato de archivo MMZ y el reciente Google Earth
dispone del formato de archivo KMZ. Este tipo de archivos (todos ellos con
capacidad de compresión) son ideales para transmitir capas del cliente al servidor
manteniendo la mayoría o toda (según el formato) la calidad de los datos originales
(geometría, geodesia, datos espaciales y alfanuméricos, tablas y documentos
relacionados, metadatos, simbolización, etc). En adelante, llamaremos a estos
formatos, formatos de intercambio. Cada servidor WPS se basa en un perfil
concreto del estándar WPS que establece claramente cómo iniciar la ejecución de
un proceso y como relacionar las capas para cada proceso disponible. Una vez
iniciado el proceso, la aplicación cliente puede consultar el estado de la ejecución
al servidor y actualizar una ventana de información al usuario. Si el final de la
ejecución da como resultado una capa, antes de dar por finalizado el proceso la
aplicación servidora deberá empaquetar el resultado en un formato de intercambio
para su entrega. Una vez la aplicación cliente conozca que el proceso ha terminado
deberá solicitar la descarga del arc