Si estás iniciándote en el mundo de la programación GIS probablemente se te haya pasado por la cabeza la idea de crear tu propio visor web. Una aplicación con un mapa interactivo que te permita visualizar información, o incluso modificarla. Quizá ya conozcas algunas librerías web de mapas (OpenLayers, Leaflet, etc.) y hayas creado tus primeros visores en tu ordenador local. Todos los programadores GIS hemos pasado por eso en nuestra etapa inicial, pero ¿luego qué? ¿Cómo desarrollamos aplicaciones más complejas? Imagina una aplicación para mostrar información catastral de un país (suelo urbanizable, parcelas y subparcelas, usos del suelo, etc.), con gestión de usuarios y capacidad de editar la información vía web.

En este post os quiero hablar de cómo se crea  una aplicación WebGIS profesional en un ámbito de producción. El resultado será una arquitectura como la siguiente:

Arquitectura aplicación

Software de escritorio

No siempre es necesario un programa GIS de escritorio, pero a menudo necesitamos tratar la información cruda antes de poder servirla. Hacer JOINs para añadir información auxiliar, generar nuevos atributos, hacer transformaciones espaciales, etc. Para ello podemos hacer uso de programas como QGIS, gvSIG o ArcGIS. Por ejemplo, imagina que queremos elaborar capas de renta per cápita y densidad de población cruzando datos de población y hacienda con los de viviendas. Necesitamos hacer algunos análisis previos partiendo de los datos originales de catastro.

Tenemos que tener en cuenta que, aunque el software de escritorio no es parte integral de nuestro sistema SIG, forma parte de su entorno de desarrollo. Podemos utilizarlo para editar datos o para gestionar aquella parte que no está expuesta al público. Usualmente no vas a dar permisos totales a los usuarios de la aplicación, sino que te vas a reservas ciertos privilegios como administrador, restringiendo aquellas partes más críticas. Piensa que nuestra aplicación de catastro tiene datos sensibles que no debería ver nadie (datos personales, presupuestos, planes de futuro, etc.) y datos que, aunque consultables, no deberían poder modificarse (direcciones de calles, usos del suelo, etc.). Todo esto lo podríamos gestionar de forma interna desde un SIG de escritorio. Si quieres perfeccionar tu dominio de QGIS puedes ojear este curso que ofrecemos en nuestra web.

Base de datos

Existen muchas formas de almacenar tanto la información espacial (shapefiles, geopackages, geojson) como la no espacial (csv, excel, txt). Cada una tiene sus ventajas e inconvenientes, pero todas ellas comparten una gran contra: no son útiles para sistemas web que se actualizan dinámicamente. En nuestra aplicación web vamos a necesitar consultar la información actualizada al momento, poder editarla, hacer transformaciones con ella y exportarla a distintos formatos, todo ello dentro de un entorno seguro y accesible desde varios clientes (aplicación web, SIG de escritorio, etc.) vía web. Estos formatos estáticos no nos aportan estas características. Un iniciado en el mundo de los SIG está acostumbrado a trabajar con ficheros espaciales locales (shapefile, geopackage), y ciertamente son muy útiles, pero tienen un alcance limitado. Pronto uno se da cuenta de que necesita algo más completo, y descubre las bases de datos.

El Diccionario de Oxford define una base de datos como un «programa capaz de almacenar gran cantidad de datos, relacionados y estructurados, que pueden ser consultados rápidamente de acuerdo con las características selectivas que se deseen«. Una base de datos tiene un tamaño enorme (sería todo un reto intentar agotar el espacio que ofrece una base de datos moderna) pero bien estructurado, con muchas herramientas para asegurar la integridad de los datos (relaciones correctas, sin duplicados, valores no erróneos, etc.). Esto último es algo muy limitado en los formatos usuales de SIG. Una base de datos es un sistema en sí mismo en el que podemos definir diferentes usuarios con diferentes permisos, además de poder ser accesible fácilmente de forma remota. Esto último es fundamental para poder ofrecer un servicio web.

Opciones disponibles

Existen diferentes estructuras de bases de datos y, dentro de las relacionales (las más comunes), destacan opciones Open Source como PostgreSQL. PostreSQL es ampliamente utilizada en el mundo de los SIG , además de su fiabilidad y rendimiento, por ofrecer una extensión espacial llamada PostGIS muy potente y versátil. Todo lo que tengamos en ficheros shapefile o geopackage puede ser almacenado en PostGIS, además de incluir muchas otras ventajas. Puedes aprender PostgreSQL/PostGIS a nivel profesional con nuestro curso de iniciación.

En aplicaciones SIG de este estilo, incluso en las más sencillas, se utilizan bases de datos para almacenar la información tanto espacial (usos del suelo, viviendas e instalaciones, mobiliario urbano) como no espacial (datos personales, recaudación de impuestos). Podemos mezclar en una misma capa estos dos tipos de datos, como sucede en un shapefile.

Servidor de mapas

Un servidor de mapas es una plataforma mediante la cual mostrar información espacial de forma rápida y sencilla, permitiendo además consultar parte de ella. Es una  buena opción cuando queremos servir información pesada con estilos complejos. Usualmente, esta información se envía mediante un protocolo WMS (Web Map Service), de forma que al cliente web se le envía la información espacial en formato imagen. Entre las plataformas más empleadas encontramos GeoServer, MapServer o QGIS Server.

Ten en cuenta que un servidor de mapas se limita a enviar la información a los clientes web, por lo que nosotros debemos suministrarle los datos en brutos. Una forma de hacer esto es guardar los ficheros de forma local en el mismo ordenador en el que está nuestro servidor de mapas, en un formato shapefile, por ejemplo. Sin embargo, ya hemos dicho que estos ficheros no son los más óptimos para almacenar la información. Por ello, tenemos la solución ideal: almacenar los datos en una base de datos PostgreSQL/PostGIS y servirlos al cliente web a través de nuestro servidor de mapas (por ejemplo, GeoServer). De esta forma, evitamos duplicados y podemos aprovechar todas las funcionalidades de un servidor de mapas.

Podríamos prescindir de un servidor de mapas para nuestra aplicación sirviendo los datos directamente desde la base de datos. Tenemos tres opciones:

  1. Mandarlas en formato vectorial mediante el protocolo WFS (Web Feature Service). Muy flexible a la hora de obtener la información pero más pesado, por lo que es ineficiente para grandes volúmenes de datos.
  2.  Rasterizar los datos como una imagen. Imitar el comportamiento de un servidor de mapas y mandar los datos como una imagen. Es rápido, pero el cliente no tiene acceso a los datos originales de la capa, lo que nos limita a la hora de hacer aplicaciones interactivas (resaltar una entidad concreta, hacer cálculos de atributos, etc.).
  3. Teselar completamente la información. En lugar de rasterizar los datos en tiempo real cada vez que se solicitan desde la web, se generan las teselas que se guardan localmente en el servidor. Cada vez que se soliciten, se envían estas teselas en formato imagen. Es mucho más rápido que el método anterior, pero no sirve para datos que se actualizan periódicamente, ya que habría que volver a teselar la información cada vez que se modifique algún valor de la capa.

Cada método tiene sus ventajas y desventajas, por lo que habrá que elegir la que mejor nos convenga. La información que no cambie habitualmente o que no vaya a usarse de forma interactiva se puede servir mediante los dos últimos métodos. Para el resto, es preferible el primero.

Backend

Si lo único que queremos es hacer una web estática que muestre una serie de capas proporcionadas por un servidor de mapas, la estructura que hemos creado hasta ahora es suficiente. El cliente web pedirá las capas directamente a GeoServer (o cualquier otro servidor de mapas) y estas se mostrarán en el navegador. Sin embargo, si queremos construir algo más completo necesitamos un controlador en el servidor que gestiones todas las partes de nuestro sistema SIG. Esto es a lo que llamamos un Backend. Probablemente este sea el apartado más desconocido para alguien que da sus primeros pasos en la programación SIG.

Seguridad

Imaginemos que la aplicación de catastro que estamos desarrollando solo va a ser accesible para usuarios registrados en el sistema. De esta forma, solo cuando un usuario inicie sesión y se verifique su identidad se le podrá enviar capas de información. Esto, a priori, no es posible hacerlo únicamente con GeoServer; necesitamos un sistema seguro que sea capaz de autenticar usuarios y, solo si el usuario es válido, mandar la información correspondiente.

En este escenario, podemos tener una tabla llamada «usuarios» en la base de datos, la cual contiene dos campos: «usuario» y «contraseña». Al usuario del cliente web se le mostrará la típica página de inicio de sesión en la que tendrá que ingresar su usuario y contraseña. Estos parámetros se enviarán a nuestro Backend, el cual está alojado en el servidor. Es entonces aquí donde se comprobará en la base de datos si el usuario y contraseña son correctos. Una vez verificada la identidad, el usuario podrá acceder al interior de la aplicación web (de otra forma no sería posible).

Cada vez que el usuario solicite cualquier tipo de información, ya sea espacial (una capa de calles de una ciudad) o no espacial (datos y estadísticas de población) la petición pasará por el Backend, el cual verificará la identidad del usuario. Hecho esto, obtendrá los valores de la base de datos, y se mandarán de vuelta al cliente para ser representados.

Si te fijas, el Backend actúa como un embudo que canaliza toda comunicación entre el cliente web y la base de datos. Desde la aplicación web NUNCA se podrá acceder directamente a la base de datos; toda interacción con ella se hará a través del Backend. Lo bueno de esto es que podemos filtrar qué información se está enviando, haciendo más seguro el sistema. Incluso, podemos enviar información diferente en función del usuario que la pide. Esto es común en las redes sociales, donde el listado de amigos o contactos es diferente para cada persona.

Servicio y análisis de datos

Un Backend no se usa simplemente para autenticar usuarios. Podemos usarlo para servir cualquier tipo de información de la base de datos sin tener que usar un servidor de mapas, procesamiento de datos, analíticas de la aplicación, descarga de ficheros (imágenes, PDFs, shapefiles, etc.) y muchas otras cosas. Piensa en un Backend como la lógica de nuestro servido, y que puede hacer todo aquello para lo que lo programemos.

Al principio del post mencionamos la posibilidad de modificar la información de nuestro sistema SIG directamente desde la web. Sin embargo, ya hemos dicho que la aplicación del cliente nunca se va a conectar directamente a la base de datos. En casos como este, lo que se hace es programar una serie de funciones en el Backend que puedan modificar la base de datos. Esto se hace mediante librerías que permiten conectarnos a la base de datos y ejecutar sentencias SQL para consultar o editar los valores. Todo ello, dentro del entorno de nuestro código y del lenguaje de programación correspondiente.

Opciones disponibles

Hay una infinitud de formas de desarrollar un Backend, dependiendo de la arquitectura de software, del lenguaje de programación y del framework que utilicemos. Cada una tiene sus pros y sus contras, y esto dependerá del tipo de servicio que queramos construir. Para ello, podemos utilizar Java, Python, Javascript, .NET, PHP, etc. Mi consejo es que, si ya conocéis un lenguaje de programación con cierta soltura, uséis ese para desarrollar el Backend. En el contexto de nuestra aplicación web os sugiero las siguientes opciones:

  • Javascript. Aunque Javascript es un lenguaje usado en el cliente web (por ejemplo, para trabajar con Leaflet/OpenLayers) también podemos usarlo en el lado del servidor gracias a Node.js, un entorno de desarrollo basado en el motor V8 de Chrome. La ventaja de Node.js es que, como hemos dicho, utiliza 100% Javascript, por lo que con un solo lenguaje de programación podemos el cliente web (Frontend) y el lado del servidor (Backend). Es muy fácil utilizarlo gracias a su framework Express.
  • Python. Este lenguaje es muy utilizado en el mundo de los SIG para analizar y procesar datos. Tiene muchas librerías para ello (adaptación de GDAL, shapely, geopandas, etc.), además de poder usarse en QGIS (PyQGIS) y ArcGIS (ArcPy). Sin embargo, también tiene su utilidad en la construcción de servicios Backend. Es fácil usando el framework Flask, o utilizar Django para desarrollos más avanzados.

Cliente web

El último paso en nuestro sistema es el cliente web, el cual es la puerta de entrada de los usuarios para utilizar nuestro sistema. Nuestra página web estará configurada para hacer peticiones a nuestro backend para responder cada vez que el usuario hace alguna acción (pedir una capa, descargar unos datos).

Desarrollo del Frontend

Como ya sabréis, una aplicación web se construye con tres elementos:

  • HTML para la estructura de la página y sus componentes.
  • CSS para el estilo de los mismo (color, posición, fuentes de texto, etc.).
  • Javascript para el apartado interactivo. Nos permite gestionar eventos (clicks de botones, etc.) y ejecutar ciertas funciones en base a ello.

Sin embargo, con el paso del tiempo se han desarrollado librerías y frameworks de programación frontend para agilizar el desarrollo y hacer aplicaciones más complejas. Este es un tema más avanzado, así que os recomiendo prescindir de cualquier framework en vuestras primeras web y utilizar los tres elementos básicos mencionados.

Usualmente, el componente central será un visor o mapa interactivo en el que se mostrará la información espacial. Para ello tenemos dos opciones:

Leaflet

Es una librería ultraligera que tiene las funcionalidades suficientes para crear un visor web. No tiene muchas funcionalidades extra incorporadas, pero se pueden añadir mediante plugins hechos por la comunidad. Es la más popular hoy en día.

OpenLayers

OpenLayers tiene una función parecida a Leaflet, pero con la diferencia de que incluye muchas más funcionalidades en su librería básica. De esta forma, podemos construir controles de capas, cargar rásters o hacer clusterización de puntos. Esto trae dos desventajas:

  • Es algo más pesada.
  • La librería está segmentada en muchas clases, por lo que la curva de aprendizaje puede ser algo más lenta.

¿Cuál es mejor?

No hay una respuesta absoluta a esta pregunta. ¿Vas a hacer un visor sencillo y no quieres que te consuma mucho tiempo? Entonces deberías probar Leaflet. Hacer un mapa básico debería llevarte cuestión de minutos. ¿Quieres algo más avanzado, uso de ráster, conexiones WMS y más dinámico? En ese caso OpenLayers será tu mejor solución. Dominar tantas funcionalidades como tiene OpenLayers puede llevar más tiempo, pero compensa saber que tienes tantas opciones disponibles incorporadas en la librería. Realmente, es posible que nunca uses la mayoría de ellas. Por el contrario, con Leaflet tendrías que construir tus propias funcionalidades a modo de plugin, y esto requiere un dominio mayor de programación (Javascript) y visores web.

En general, ambas librerías ofrecen el mismo servicio de una manera muy parecida. Usa la que más te convenza y no tendrás problemas para generar tu visor web. Si quieres aprender más de desarrollo de visores web usando Leaflet y OpenLayers, échale un vistazo a nuestro curso.

En conclusión

Hay multitud de métodos y tecnología para desarrollar el sistema de una aplicación web. Estas son solo algunas de las opciones disponibles en cada etapa:

  • Software de escritorio
    • QGIS
    • gvSIG
    • ArcGIS
  • Bases de datos
    • PostgreSQL – PostGIS
    • Oracle – Oracle Spatial
    • SQL Server
    • SQLite
    • MySQL
  • Servidores de mapas
    • GeoServer
    • MapServer
    • QGIS Server
  • Backend
    • Node.js
    • Python
    • Java
    • .NET
    • PHP
  • Frontend
    • Javascript estándar
    • jQuery
    • React
    • Angular
    • Vue
  • Visor de mapas
    • Leaflet
    • OpenLayers

Tenemos muchas opciones para cada uno de las etapas de nuestro sistema. Mi consejo es que no intentes dominarlas todas, pues es un trabajo inabarcable para alguien en proceso de aprendizaje. Limítate a aprender una o dos tecnologías de cada rama, e intenta perfeccionarla lo máximo posible. Es mejor dominar una tecnología (ya sea un software, un lenguaje de programación o una librería) y saber explotarla que apenas conocer los conceptos básicos de varias de ellas.

1 estrella2 estrellas3 estrellas4 estrellas5 estrellas (7 votos, promedio: 4,43 de 5)

Cargando…

Formación de calidad impartida por profesionales