Autor: Constantino Sánchez Ballesteros

Analista/Programador del Dpto. de Informática de Sgrin, S.A. - Grupo CADIC

Aplicaciones GIS en el ámbito Web

Con el avance de las nuevas tecnologías, remarcado especialmente en el campo del Software y el aumento progresivo de la potencia del Hardware en el parque informático tanto a nivel de usuario como profesional, se requieren nuevos servicios que mejoren la experiencia de usuario en las aplicaciones de hoy.

Actualmente empieza a sonar con fuerza la Web 2.0, término muy utilizado con el advenimiento de nuevas propuestas para la Web como Weblogs, sindicaciones RSS, etc. En el tema que nos ocupa en este artículo y más concretamente hablando de Interfaces de usuario para la Web, buena culpa de este boom lo tiene la emergente tecnología AJAX, englobada dentro de las RIA (Rich Internet Application); actualizaciones parciales de página, menor latencia en los servicios, menor consumo de ancho de banda, funcionalidades de escritorio...

El aprovechamiento de estos recursos ha permitido que se empiecen a ver aplicaciones Web que, en muchos aspectos, nada tienen que envidiar a sus homónimas de escritorio. Google Maps, por ejemplo, ofrece servicios de localización y visualización de cartografía, tanto vectorial como Raster, mostrando una agilidad pasmosa y consultada por muchos usuarios de forma concurrente.

En adelante descubrirá cómo desarrollar este tipo de aplicaciones orientadas al mundo GIS mediante la plataforma de desarrollo LatinoObjects, que hace buen uso de los recursos citados anteriormente.

 

Cuadro de texto:
Proyecto Web desarrollado con el visor Web de LatinoObjects

LatinoObjects como plataforma de desarrollo

Uno de los productos integrados en LatinoObjects es el Visor Web. Este componente se basa en .Net Framework 2.0 y el modelo de componentes que propone Microsoft en la arquitectura ASP.NET 2.0. Está especialmente optimizado para sacar el máximo provecho de AJAX en el explorador del cliente y obtener el mejor rendimiento sirviendo cartografía desde el servidor de forma concurrente. Para ello interacciona con LatinoServer, servidor geoespacial de la familia de productos Latino que se encarga de alimentar al visor Web con datos gráficos y alfanuméricos contenidos en formatos tan dispares como ECW (Raster), DGN, DWG, SHAPE, VEC, Base de datos (p.e. MySQL, SQL Server) e incluso obtenidos de otros servidores espaciales como ArcSDE o MapServer.

 

Características del Visor Web

La principal característica de este componente es la visualización de Ortoimágenes y vectoriales de forma progresiva. Para lograrlo, se basa en la composición de la vista mediante Tiling, que permite visualizar una imagen completa mediante trozos más pequeños de ella. Con este sistema se logra una mayor escalabilidad en el servidor y una mejor experiencia de usuario puesto que no hay que aguantar largas esperas para componer una imagen de tamaño considerable y enviarla de una sola vez al explorador del cliente.

Hay que tener en cuenta que una imagen completa visualizada en el visor puede rondar los 300/400 Kb. Dependiendo del ancho de banda del usuario, en la mayoría de los casos es contraproducente enviar toda esa información de una sola vez. Trozos de unos 20/30 Kb. son tamaños razonables para una visualización ágil de la información gráfica.

A continuación se detallan algunos aspectos internos de la arquitectura del visor:

 

 

Botones automatizados y personalizados

El visor viene ‘de fábrica’ con una serie de botones, instanciables tanto en tiempo de diseño como programáticamente. Están ideados para trabajar como comandos y ejecutar una tarea concreta. A continuación se detallan los más importantes y su funcionalidad:

 

 

Además de estos botones, se puede subclasificar de varias clases base (p.e. LtnWVButtonPush o LtnWVButtonAction) para crear botones con funcionalidad personalizada al hacer click sobre ellos.

 

Postback y el estado del visor

Un detalle a tener en cuenta es que el visor mantiene su estado totalmente en el explorador del cliente (salvo ciertos objetos asignados programáticamente en su inicialización en el servidor). ASP.NET, desde sus orígenes, se ha caracterizado por la utilización de Postback para notificar cambios de estado en la interfaz (p.e. eventos de controles) o simplemente envío de datos al servidor. Esto presenta, a priori, tres problemas serios:

 

  1. Obliga a reconstruir/recargar la página en cada solicitud: esto implica un aumento de procesamiento en el servidor y mayor latencia en la respuesta al cliente.
  2. Efectos colaterales en la interfaz del cliente: como parpadeos de página.
  3. Pérdida del estado del visor: puesto que el estado se mantiene en el cliente, a cada Postback se perdería la situación actual del visor en ese preciso instante (escala, nivel de zoom, caché, etc.).

 

Teniendo en cuenta esos puntos, es necesario utilizar vías alternativas que disminuyan o eliminen estos inconvenientes. Microsoft recientemente ha liberado un Framework (Microsoft AJAX ASP.NET) que permite, entre otras cosas, la actualización parcial de página y un conjunto de controles de servidor para lograr, a nivel de interfaz, comportamientos avanzados como animación de controles, soporte Drag and Drop, máscaras de entrada de datos...

En mi opinión, la característica más importante es la actualización parcial de página. Mediante un control de servidor denominado UpdatePanel es posible actualizar, a cada Postback generado por un control incrustado en él, el contenido que resida en dicho panel sin necesidad de recargar las partes restantes que conforman la página. Y lo que es más importante, mantiene el estado en el que se encontraba la interfaz gráfica en ese momento en el explorador del cliente. Además pueden coexistir varios UpdatePanel en la misma página que se procesarán y actualizarán de forma independiente en base al que generó la solicitud al servidor.

 

LatinoServer como complemento del visor

Para sacar el máximo provecho a la hora de servir cartografía, la familia de productos Latino incluye un servidor geoespacial de alto rendimiento que se acopla perfectamente a las necesidades del visor Web. Gestiona formatos de CAD de diversa índole como ECW, DGN, DWG, SHAPE e incluso de otros servidores espaciales como ArcSDE o MapServer. En el caso del formato ECW (Raster) permite activar tanto caché de disco como caché de memoria aumentando considerablemente el rendimiento a la hora de atender solicitudes del visor previamente procesadas.

Respecto a la seguridad, LatinoServer incluye soporte de autentificación vía LatinoPassport que permite definir seguridad a nivel de proveedor de datos que se quiere publicar.

Proyecto de ejemplo

Vamos a abordar el desarrollo de un ejemplo sencillo que muestra un visor Web con dos proveedores combinados (uno Raster y otro vectorial). Para poder desplegar este proyecto, el lector debe instalar el Framework AJAX ASP.NET de Microsoft y tener, al menos, una licencia de LatinoObjects.

 

Cuadro de texto:
Página principal de Microsoft AJAX ASP.NET

 


Un botón se encargará de ver/ocultar el proveedor Raster mediante un Postback generado por su evento click. Para no perder el estado del visor en el cliente, el botón se incrustará en un control UpdatePanel de AJAX ASP.NET.

El primer paso es crear un nuevo sitio Web. Dentro de Visual Studio 2005, abra el menú Archivo/Nuevo/Sitio Web. Aparecerá una pantalla en la que debe seleccionar el Item ASP.NET AJAX-Enabled Web Site.

En este punto se creará una nueva solución junto con el proyecto correspondiente. Para poder agregar el visor Web en tiempo de diseño a la página y tener acceso a su API en el código de servidor, será necesario referenciar el ensamblado OLatino.dll en el proyecto y agregar una nueva ficha en el cuadro de controles de Visual Studio seleccionando el ensamblado citado. Hecho esto nos aparecerán en la ficha numerosos controles, entre los que se encuentra el correspondiente al visor web: LtnWebViewer.

 

Cuadro de texto:
Página principal del ejemplo en tiempo de diseño dentro de Visual Studio 2005

 


Puesto que el visor funciona mediante un Handler de ASP.NET, debemos declararlo en el archivo Web.config de nuestro WebSite, dentro de la sección system.web del siguiente modo:

 

Cuadro de texto: <httpHandlers>			
<add path="MapServer.ashx" verb="*" type="OLatino.LtnWebViewer.LtnWebHandler, OLatino"/>
</httpHandlers>
 


Si ya existe el Tag httpHandlers, agregaremos sólo la declaración sin el Tag. En el siguiente listado se muestra el código fuente en C# que se agregará a la página de inicio del proyecto:

 

Cuadro de texto: protected void Page_Load(object sender, EventArgs e)
    {
        if (!this.IsPostBack)
        {
            //carga proveedores
            LtnProvider prv1 = LtnProvider.FromName("HTTP");
            LtnProvider prv2 = LtnProvider.FromName("HTTP");
            LtnRESULT res1 = prv1.Open("localhost", "invitado", "raster", "");
            LtnRESULT res2 = prv2.Open("localhost", "invitado", "vector", "");

            if (res1 == LtnRESULT.LR_OK && res2 == LtnRESULT.LR_OK)
            {
                //Setup del Visor Web y LtnViewer asociado
                LtnViewer v = new LtnViewer();
                v.sources.Add(prv1);
                v.sources.Add(prv2);

                //Display Settings para el vectorial
                XmlDocument doc = new XmlDocument();
                doc.Load(Server.MapPath("") + "\\proyecto.ltnprj");
                LtnDisplaySettings d = new LtnDisplaySettings();
                d.LoadConfig(doc);
                v.SetDisplaySetting(d);	

    //Visualización inicial y límites
                LtnPoint3D pMin, pMax;
                v.sources.Bounds(out pMin, out pMax);

                this.visor.SetBounds(pMin, pMax);
                this.visor.SetViewWindow(pMin, pMax);
                this.visor.ViewerHandler = v;

                Session["RASTER"] = prv1; //guarda proveedor para uso posterior
            }
            else //ooops!!!
            {
                Response.Write("No se ha podido cargar mapa...");
                Response.End();
            }
        }
    }

    //Evento Click del botón
    protected void btnRaster_Click(object sender, EventArgs e)
    {
        LtnProvider prvRaster = (LtnProvider)Session["RASTER"];
        prvRaster.Enabled = !prvRaster.Enabled;

        string cmd = "visor.ClearCache();visor.RefreshView();";
        ScriptManager.RegisterStartupScript(this, this.GetType(), 
   "raster", cmd, true);
    }
 


También será necesario agregar al directorio bin del WebSite una carpeta llamada Providers que debe contener los proveedores que se utilizarán para la visualización de cartografía. En el ejemplo se utilizará únicamente un proveedor socket (LtnProviderSocket.dll) que se comunicará con LatinoServer.

Si observa detenidamente el código fuente de la página principal apreciará que existen tres partes bien diferenciadas para configurar correctamente el visor Web:

 

  1. Carga de proveedores de datos gráficos.
  2. Inicialización de LtnViewer asociado al visor Web, agregándole proveedores y proyecto de visualización si se utilizan vectoriales.
  3. Inicialización de visor Web definiendo la ventana inicial y los límites de visualización.

 

Todo visor Web necesita tener asignado una instancia de LtnViewer en el que delegar, ya que será este último el que se encargue de dibujar los datos gráficos de manera conveniente. El código crítico se encuentra en el método btnRaster_Click. Éste será invocado a cada Postback generado por el botón de apagado/encendido del Raster. Dentro de este método activamos o desactivamos el proveedor Raster y notificamos al visor que actualice la vista para reflejar los cambios. Nótese que la manipulación del visor se hace mediante el API Javascript del visor, debido a que, como se ha comentado en un apartado anterior, el estado del visor se mantiene en el cliente (navegador del usuario) y por lo tanto es la manera adecuada de poner notificarle cambios de estado.

 

Conclusión

La oferta y demanda de servicios en Internet actualmente es bastante exigente debido, en gran parte, a la proliferación de nuevas tecnologías, mayores usuarios “enganchados” a la Red, aumento de ancho de banda por parte de los ISP (proveedores de servicios de Internet), etc. En el mundo GIS esta exigencia se agrava aún más ya que este tipo de aplicaciones ofrece una cantidad ingente de información al usuario, ya sea de forma alfanumérica o gráfica.

Responder al usuario de estos servicios orientados a GIS de manera eficiente requiere una buena plataforma de desarrollo que cumpla las expectativas de desarrollos actuales y futuros. En este artículo se ha pretendido acercar algunas de las posibilidades de la plataforma Latino en este sentido.

 

Referencias