Nuevos Proyectos: Igo software resulta adjudicataria de la Realización de un Geoportal de Internet para la consulta de datos relacionados con los ecosistemas fluviales para la Consejería de Industria, Energía y Medio Ambiente de la Junta Extremadura

Igo software creará un Geoportal de Internet que podrá gestionarse a través de un gestor de contenidos intuitivo y amigable para el usuario, que siguiendo con lo exigido en el Pliego de Prescripciones Técnicas, podrá ser visualizado en cualquiera de los navegadores que más se usan en la actualidad, contará con información que podrá ser editada por el personal técnico de la Consejería y que se implementará como una Infraestructura de Datos Espaciales (IDE), implementando servicios WMS, WFS, WCS, Catálogo y WPS, y siguiendo con los estándares de compartición de datos y de formato que establece la normativa europea, lo que le permitirá integrarse con otras herramientas que precisen información geográfica.

Este portal estará compuesto de dos partes, en primer lugar, la portada en la que se presentará el proyecto y en la que se tendrá acceso a información del mismo. En esta parte también se encontrará información sobre otras IDEs, estándares, clientes para la IDE, metadatos, etc. En segunda instancia, un cliente de visualización de cartografía e información desarrollada.

Durante la ejecución de este proyecto se recopilarán, catalogarán, adaptarán y migrarán los datos ya existentes en el servicio de de Recursos Cinegéticos y Piscícolas, relacionados con los ecosistemas acuáticos en Extremadura que deban ser incluidos en el portal. Para ello Igo Software se encargará de hacer que los datos sean de fácil y sencillo acceso para el personal técnico, utilizando bases de datos espaciales que permitan el almacenamiento versionado de los datos y su acceso concurrente.

Igualmente,usando las librerías de javasripct Openlayers, se desarrollará el visualizador con el que se presentarán gráficamente los servicios del Geoportal, incluyendo la implantación del servicio de búsquedas en catálogos de datos y utilización de servicios de nomenclator. Por su parte se implementará un cliente pesado que aporte funcionalidades tales como, edición y creación de capas, creación de análisis geoestadístico, de redes y creación de plantillas de mapas.

Para ello Igo Software, siguiendo los lineamientos de la Consejería, realizará una serie de tareas con las que cumplirá a cabalidad con los requerimientos de esta contratación:

• Recopilación y adaptación de los datos existentes en el Servicio de Recursos Cinergéticos y Piscícolas, concretamente en la sección de Pesca.

• Publicación de datos geográficos.

• Desarrollo e implantación del Geoportal.

• Disposición e integración de las herramientas GIS para los futuros trabajos de mejora y ampliación de la información disponible.

• Formación.

Todo el desarrollo de este proyecto se realizará, como siempre, siguiendo los controles y estándares de calidad habituales en nuestra empresa. Próximamente os informaremos sobre los adelantos en el proyecto.

Inventario Forestal realizado con Láser Escáner.

Igo Software está investigando junto con la Consejería de Industria, Energía y Medio Ambiente el desarrollo de una metodología para el inventariado y caracterización de parámetros dasométricos en masas forestales mediante escáner láser.

Se trata de una nueva herramienta que dará soporte a las actuales políticas de la Comunidad de Extremadura sobre gestión y aprovechamiento sostenible de los recursos Forestales. Una de sus funciones será la de complementar los actuales proyectos que está desarrollando la Consejería de Industria, Energía y Medio Ambiente, relacionados con la valoración energética de la biomasa forestal, ejecutando tareas de control de calidad y precisión.
Este prototipo conjuga una serie de nuevas tecnologías que se verán finalizadas con la implementación de un SIG, que a su vez aprovechará nuevas herramientas y aplicaciones ya implementadas como Sextante.
Como resultado final se obtendrá de una metodología idónea para la realización de inventarios de biomasa forestal rápidos, económicos, precisos y automatizados. Un aspecto innovador y muy relevante de este trabajo es la utilización de nuevas tecnologías que permitan aumentar la velocidad de muestreo y mejorar la explotación de los datos. Para ello Igo Software, cuenta con una novedosa herramienta en cuanto al sistema de recolección de datos, se trata del Escáner Láser Terrestre Faro LS Photon, con el cual se podrán recolectar una gran cantidad de datos en campo, de manera tridimensional y así mismo, geolocalizarlos. De esta forma se podrá automatizar el cálculo de datos y la estimación del inventario de biomasa.
Dicha metodología se dividirá en 4 partes, el Diseño del trabajo de campo, la ejecución del trabajo de campo, la exportación de los datos de campo al programa (Sextante) y la explotación de los datos en un SIG.
Para ejecutar las tareas de trabajo de campo se diseñará una toma de muestra representativa, lo suficientemente amplia para que pueda ser utilizada por los estadísticos habituales y para que a su vez pueda compararse con los datos obtenidos a partir de inventarios anteriores realizados con medios distintos, con el fin de cubrir dicha muestra se realizarán las tomas de escáner que sean necesarias en cada una de las muestras para obtener todos los datos necesarios.
Este muestreo se realizará aprovechando el inventario de biomasa que durante los próximos meses realizará la Consejería de Industria, Energía y Medio Ambiente, así ambos trabajos se complementarán en cuanto al control de calidad, que será mutuo, y permitirá a su vez comparar los resultados obtenidos en los distintas metodologías.
Básicamente durante esta fase del proyecto las tareas consisten en desplazarse hasta las parcelas donde se realizará el muestreo y obtener, con el láser escáner, un modelo en tres dimensiones del lugar. A partir de la nube de puntos obtenida por el escáner se podrán calcular parámetros como, el número de pies en la parcela, el tamaño y el volumen de la biomasa, entre otros. Paralelamente a esta toma, se realizará un muestreo utilizando metodologías tradicionales cuyos resultados serán comparados con los obtenidos por el escáner.
Además del muestreo, se tomarán fotos y se posicionará con GPS la nube de puntos para posteriormente incluirla en el SIG.
Para este proyecto se diseñará un software que automatizará las tareas de tratamiento de las nubes de puntos resultantes de las muestras georreferenciadas obtenidas durante el trabajo de campo. Estas tareas consisten en la eliminación de ruido, eliminación de puntos sobrantes según el tamaño de la parcela, procesado de la nube para obtener mayor cantidad de parámetros forestes, implementación de estadísticos que permitan extrapolar la cantidad de biomasa y por último la realización de un volcado de datos en un SIG (gvSIG, Sextante o Meigas).

Haciendo tile cache de WMS en ubuntu

Tile cache en WMS es una técnica que consiste en tener el mapa cortado en trocitos y cacheado de forma que el servidor no tiene  que estar generando una imagen cada vez que se hace una petición. De esta manera trabaja kamap, google maps, etc…

Estábamos intentando poner entre en el server (Mapserver en nuestro caso) y el cliente (Openlayers en nuestro caso) algo que nos hiciera es tile cache y que fuera lo más independiente de ambos que se pudiera.

Empezamos a tratar el tema usando GeoWebCache, tenía muy buena pinta, parecía fácil de configurar y ligerito. Nos metimos en faena y después de un rato nos sale:

org.geowebcache.GeoWebCacheException: GeoWebCache only handles EPSG:4326 and EPSG:900913!

¡Sólo soporta esas dos proyecciones!

Buceando un poco en la documentación parece ser que estas dos proyecciones son las recomendadas por el OGC para hacer tile cache

http://blog.geoserver.org/2008/03/12/geowebcache-070/

Tras trastear un poco decidimos descartarlo por ahora y nos lanzamos a buscar alternativas y había dos (Gracias Xurxo). En primer lugar ka-map! pero usando como cliente openlayers.Esta opción la descartamos por su fuerte dependencia de mapserver y porque estamos esperando a la version siguiente que funcionará ya con openlayers, aunque me quedé con ganas de probarlo pero no teníamos tanto tiempo y en segundo lugar TileCache de  mercarta. Es una pequeña librería de python que funciona sobre apache y fue por la que al final nos decantamos.

Voy a escribir aqui las cosas que tuvimos que hacer para que nos funcionara TileCache.

En primer lugar es necesario que nuesto apache ejecute python.

Para instalar apache2 y el mod_python seguí al pie de la letra este post y me funciono directamente

http://tru3n0.com/index.php/2007/10/18/instalar-apache2-mod_python-en-debian/

Y ahora viene lo que es la configuración en sí del TileWebCache

1 . Bajar la aplicación de http://www.tilecache.org/

2. El tar que bajamos, lo descomprimimos en la carpeta accesible por apache, típicamente en ubuntu y con todo bajado por apt esta carpeta es /var/www con lo que el directorio de tilecache será

/var/ww/tilecache

Al descomprimir en la carpeta tilecache hay varios archivos en el directorio. Como lo estamos haciendo con mod_python, el archivo tilecache.cgi debe ser renombrado a tilecache.py.

3. Editamos el archivo

/etc/apache2/sites-available/default (en mi caso)

y añadimos:

 <Directory /var/www/tilecache/>
AddHandler mod_python .py
PythonHandler TileCache.Service
PythonOption TileCacheConfig /var/www/tilecache/tilecache.cfg
PythonPath "['var/www/tilecache/'] + sys.path
PythonDebug On
</Directory>

La opción PythonPath arregla el error:

ImportError: No module named TileCache.Service

Este error me estuvo volviendo loco durante un buen rato, evidentemente ahí hay que poner
los paths que tenga cada uno a tilecacache

Después de tocar este archivo hay que reiniciar apache,  pero ya podemos ver si funciona tilecache poniendo en nuestro navegador lo siguiente:

http://localhost/tilecache/tilecache.py?LAYERS=basic&SERVICE=WMS%20&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:4326&BBOX=-180,-90,0,90%20&WIDTH=256&HEIGHT=256

Si nuestro apache está montado en otro path o con otra ip, pues habrá que poner la url correctamente

4. Tile Cache ya funciona, ahora tenemos que añadir nuestras propias capas para tener una instalación completa. Esto se hace editando el archivo tilecache.cfg .

[cache]
type=Disk
base=/temp/tilecache

Con el parámetro anterior se fija el path donde se guardan los tiles en el disco

Para conocer lo que significan todos los parámetros debemos consultar:

http://www.tilecache.org/readme.html#configuration

En mi caso el archivo de configuración es:

type=WMSLayer
url=http://localhost:80/cgi-bin/mapserv?map=/var/www/cultura/cultura.map
layers=municipios
extension=png
srs=EPSG:23030
extent_type=loose
bbox=107897, 4201010, 360935, 4490145
resolutions= 564.716797,282.358398,141.179199,70.589600,35.294800,17.647400,8.823700,4.411850,2.205925,1.102962,0.551481,0.275741

Los parámetros mś complicados de averiguar fueron las resoluciones disponibles, pero con la ayuda de firebug, viendo las peticiones que hacía mi cliente te openlayers para cada nivel de zoom pude ir averiguando las resoluciones, segun la documentación, si fijamos maxresolution tile cache automáticamente genera un array con las resoluciones permitidas.

Funciona bastante bien por ahora, tendremos que verlo en el servidor…

gvSIG corriendo dentro de un mundo virtual

Hemos estado probado java-wonderland , este proyecto es la apuesta de Sun microsystems para entorno virtual multiusuario en 3D.

Tiene algunas características especialmente interesantes como es el streaming de voz y la compartición de aplicaciones.

Su roadmap promete mucho y es una herramienta que debemos tener en cuenta.

El experimento ha sido abrir gvSIG dentro de una habitación de este entorno virtual, 2 usuarios podíamos interaccionar con la aplicación y trabajar con nuesta cartografía.

En este caso abre un proyecto que se conecta a un servidor WMS.

En el vídeo podemos ver como resultó:

Congreso SIG libre Girona. Comunicación. Uso de comet en los SIG. Prototipo de SIG Colaborativo

Uso de Comet (Reverse AJAX) en los SIG. Prototipo de SIG colaborativo.

Diego Gómez Deck⁽¹⁾, Manuel de la Calle Alonso⁽²⁾ ,Vidal Toboso²⁾ y Raquel Martínez⁽¹⁾

⁽¹⁾ Consultar. diego@consultar.com

⁽²⁾ Fomento y Medio Ambiente de Extremadura (FOMEX). Santiago Caldera Nº 4 Cáceres. mdelacalle@fomex.es

Resumen

 

En los últimos meses las empresa FOMEX y Consultar han estado desarrollando unos prototipos usando técnicas de Comet para demostrar su utilidad en el campo de los Sistemas de Información Geográfica.

Comet es una técnica de programación Web que consiste en dejar una conexión abierta entre el servidor y el navegador de internet. Con esta técnica el servidor web, envía datos al cliente ligero sin necesidad de una petición explícita. Esta tecnología permite el trabajo colaborativo en tiempo real, puesto que el cliente en un navegador web cualquiera recibe información sin necesidad de pedirla o actualizar la página web. Con este procedimiento se consigue llevar a los clientes ligeros que funcionan en cualquier dispositivo y sistema operativo funcionalidad que hasta el uso de estas técnicas no estaban disponible.

Esta técnica difiere de la programación web tradicional en la cual se enviaba una página completa para cada petición, y también difiere de Ajax en la cual los datos están ya en el cliente y son obtenidos por conexiones traseras

Técnica	Forma de enviar los datos con respecto a las acciones del usuario	Forma de enviar los datos con respecto a las acciones del navegado
Web Tradicional (Refresco de página)	Síncrono	Síncrono
AJAX	Asíncrono	Síncrono
Comet (Reverse AJAX)	Asíncrono	Asíncrono

 

Existen numerosos implementaciones de Comet, pero hasta ahora no ha sido muy usada en los SIG, donde puede tener muchas posibilidades sobre todo para trabajo de campo con dispositivos en los que no tenemos disponible más que un navegador de internet

Los productos que se han usado para los prototipos son gvSIG, Geoserver, openlayers, postgis, asteroid,ST2JS y SWT.

 

Key words: Comet, Reversed Ajax, Web, Ajax, gvSig, Postgis, Geosever, Asteroid, SWT.

 

 

Introducción

El propósito de esta comunicación es intentar evaluar las posibilidades que existen para el mundo del SIG con el uso de la técnica Comet .

Existen bastantes implementaciones de esta técnica y empieza a ser ya usada en numerosos productos tanto libres como comerciales, pero no hemos encontrado aún muchas aplicaciones en el campo de los SIG y creemos que puede ser muy útil para conseguir dotar de mayor interactividad a clientes SIG ligeros, superando las limitaciones impuestas por ejecutarse dentro de un navegador.

Comet

Comet es una técnica de programación que permite que el servidor envié asíncronamente datos al cliente web sin que éste lo haya solicitado. Este procedimiento es conocido también como server push, HTTP push, HTTP streaming, Pushlets, Reverse Ajax.

Las aplicaciones web tradicionalmente han tenido una serie de limitaciones en relación a las aplicaciones de escritorio, esto, en los últimos años ha cambiado, de manera que cada vez más funcionalidad que encontramos en los clientes pesados, la tenemos en los clientes ligeros, y con técnicas como comet sin necesidad de instalar ningún plugin ni programa externo, funcionando en todas las plataformas y en todos los navegadores de internet.

Las aplicaciones tradicionales sólo podía recibir datos cuando los pedían al servidor, además con cada petición se recargaba toda la página en función del envio de los formularios, los primeros clientes ligeros sig son de esta manera, se usan los eventos del ratón para hacer una petición WMS que nos devuelve una imagen con el mapa pedido.

El siguiente paso ha sido el uso de AJAX (Asynchronous JavaScript And XML), mediante esta técnica conseguimos el uso de comunicación asíncrona con el servidor en segundo plano, este procedimiento es una combinación de varias tecnologías que ya existían anteriormente. Con AJAX se consigue pedir únicamente los datos que necesitamos que sean actualizados, un ejemplo de aplicación SIG con AJAX es Google Maps, donde se utilizan conexiones traseras además de precacheo de imágenes.

Todavía queda por resolver la comunicación servidor-cliente sin enviar una petición, esto se ha hecho hasta no hace mucho usando plugins para el navegador, aunque esto presenta algunos inconvenientes (Necesidad de distintos plugins según navegador-Sistema Operativo, obligación de hacer instalaciones suplementarias para el usuario,…) o utilizando el procedimiento de AJAX con polling, esto significa tener un proceso que actualiza los datos cada cierto periodo de tiempo, los resultados son muy similares a los que se obtienen con comet pero tienen el inconveniente del derroche de recursos, ya que se abre una conexión sin saber previamente si es necesario, en aplicaciones con poco cambio de información o con cambios muy previsibles puede funcionar correctamente.

El paso que falta es el que se consigue con comet. El servidor envía información al navegador sólo cuando lo necesita, de esta forma se disminuye la latencia y conseguimos la comunicación asíncrona en ambos sentidos. Esto dota a los clientes ligeros de una gran capacidad de interactividad, y nosotros pensamos que esta interactividad puede ser usada entre otras cosas para trabajar con SIG.

Hay dos formas básicas de hacer el comet, y dentro de esas dos numerosas implementaciones que utilizan unos procedimientos u otros, básicamente las dos técnicas principales son:

• Streaming. El servidor abre una conexión con el navegador y no se cierra nunca, el servidor envía datos que el navegador va interpretando al vuelo.

• Long Poll. El servidor mantiene una conexión durante un periodo de tiempo determinado o hasta un evento, si no ocurriese nada, el server cierra la conexión y la vuelve a abrir de nuevo.

Para realizar nuestro experimento hemos utilizado la implementación de comet asteroid [1]. Esta implementación es por streaming y consiste en mantener un Iframe abierto que recibe javascript y que el navegador interpreta según lo va recibiendo.

Nuestro aplicativo de prueba ha consistido en implementar OpenLayers dentro del framework SWT, de manera que podemos distribuir eventos usando todas las librerías de openlayers.

De hecho nuestra aplicación va a consistir en utilizar comet para distribuir eventos entre clientes ligeros sin petición previa. Es un caso típico de gestión de emergencias, la central avisa a los clientes de un evento concreto.

Arquitectura usada

El funcionamiento de la aplicación experimental sería el siguiente: desde un puesto de control que funciona sobre gvSig, donde tenemos la misma cartografía que los clientes ligeros, se envían eventos a un servidor web donde corre el framework SWT (Squeak Web Toolkit), éste se encarga de distribuir estos eventos entre los clientes. Por otra parte existe un nivel de interacción más, ya que desde los clientes se pueden enviar eventos al servidor y éste se encarga de distribuirlos a todos los clientes y al propio puesto de control.

Pormenorizando un poco el trabajo desarrollado:

• Postgre-Postgis: Simplemente almacenamos en la base de datos la información geográfica que vamos a mostrar en los mapas, alimenta al servidor de mapas y al puesto de control directamente por jdbc.

• GvSig: En gvSig hemos simulado un puesto de control donde el operador tendría toda la información, la cartografía y la capacidad de análisis sin las limitaciones de los clientes ligeros. Se ha programado una extensión de gvSIG que envía a el framework un evento en concreto indicándole su posición geográfica y el encuadre de la zona dentro de todo el territorio que es servido desde Geoserver. Por otra parte desde un navegador en el puesto de control se puede comprobar el estado de los eventos distribuidos a los clientes. La comunicación entre postgis y el framework se hace a través del envio de una URL por el método GET desde a gvSIG.

• Geoserver: Geoserver nada más que se decica a servir los mapas por protocolos estándar de forma que puedan ser visualizados por clientes tanto ligeros como pesados.

• SWT-OpenLayers. Es el framework que se encarga de distibuir los eventos lanzados por el puesto de control. SWT (Squeak Web Toolkit) es un framework de propósito general para el desarrollo de aplicaciones web que está desarrollado sobre squeak que es a su vez un subconjunto de Smalltalk.

 

 

Figura 1: Arquitectura de la aplicación.

 

Éste framework se basa en que una aplicación tiene 2 partes bien definidas, una parte cliente, que corre en los navegadores en Javascript, y una parte servidora, que corre sobre Smalltalk con un web server basado en Comet. La parte cliente, no es programada en Javascript, sino que se desarrollo todo sobre Smalltalk. El framework provee un traductor a Javascript, denominado ST2JS. Este traductor respeta prácticamente toda la semántica Smalltalk y provee un juego de clases base para crear un mini-ambiente. Por lo tanto, al desarrollar se asume que en el cliente cuenta con un Smalltalk corriendo sobre cualquier navegador que soporte a Javascript. La parte servidora, es un servidor web con Comet, esta característica es la que vamos a aprovechar para nuestro desarrollo.

La comunicación entre los dos mundos

La comunicación entre el cliente y el servidor es transparente para el desarrollador, ya que el framework realiza la conexión entre ambos a través del uso de estándares web como RPC, con XML y usando JSON para serializar los objetos que pasan del cliente al servidor y viceversa. No todos los objetos son pasados por copia al cliente y no todo regresa al servidor, como sabemos, es muy costoso pasar tanta información sobre la red, es por ello, que el framework realiza ciertas optimizaciones sobre esta capa de comunicación. Los objetos del modelo de nuestro aplicativo son referencias remotas, por lo tanto, en el cliente tenemos objetos que representan a los objetos que están del lado del servidor, y solo los objetos que pasan por copia son aquellos objetos que son parte del soporte de la comunicación.

ST2JS

Este traductor respeta prácticamente toda la semántica de Smalltalk y la traduce a Javascript. Es decir, en Smalltalk podemos tener clases, instancias, mensajes de instancia, mensajes de clase, bloques, esto el traductor lo traduce a otros recursos, pues Smalltalk y Javascript no son semánticamente simétricos, pero que al final, terminarán haciendo lo que se describe en Smalltalk.

SWT y OpenLayers

El trabajo específico que se realiza sobre el Framework es modelar las clases y eventos necesarios para que Openlayers pueda funcionar ejecutado desde el servidor de SWT.

Lo que se hace es envolver los objetos javascript de Openlayers en objetos smalltalk, de manera que el javascript que genera el framework se entiende perfectamente con todas las demás librerías de Openlayers.

A partir de esto, los eventos generados por nuestro centro de control son distribuidos por el framework.

El uso de esta herramienta nos ofrece numerosas ventajas como:

• Escritura del código sólo en un lenguaje independizándos de los navegadores y sistemas operativos
• Modelo MVC Distribuido
• Uso de una implementación de comet directamente sin tener que tocar nada del código del servidor web.

 

Conclusiones

Las posibilidades dentro del mundo SIG pensamos que pueden ser muy grandes, y que acercan las funcionalidades de los clientes pesados a la de los lilgeros, por otra parte, aunque el ancho de banda disponible es cada vez más grande, técnicas como esta permiten una mayor optimización de los recursos y una mayor posibilidad de colaboración en interacción entre los usuarios.

Si a técnicas como esta, añadimos el desarrollo de servicios como WPS, podemos estar próximos a no necesitar en la mayoría de los puestos de trabajos más que un navegador de internet (con las ventajas que esto conlleva) para tener toda la funcionalidad necesaria en un SIG

Referencias

 

• GOMEZ-DECK D.(2006) Asteroid,(A small Comet) http://wiki.squeak.org/squeak/5851

• WIKIPEDIA. Comet.

• KHARE R. (2005), Beyond AJAX: Accelerating Web Applications with Real-Time Event Notification

• GOMEZ-DECK D. ST2JS . http://www.squeaksource.com/ST2JS.html

• GOMEZ-DECK D. SWT. http://www.squeaksource.com/SWT.html

• http://ceibo.wordpress.com

• http://igosoftware.wordpress.com

La comunicación en PDF. comunicacion04.pdf