4  Cartografía

4.1 Cartografía web

Los mapas web interactivos permiten la distribución de información espacial en la web. Una aplicación de mapas web puede ser independiente en el navegador o puede integrarse en un sitio web. Se proporcionan al usuario herramientas de navegación interactiva como panorámica y zoom. Además, se puede agregar una interfaz gráfica de usuario (GUI) completa que puede albergar una serie de herramientas y funcionalidades de consulta. Las ventanas emergentes y los ‘mouse-overs’ pueden proporcionar información/enlaces adicionales.

Los mapas web pueden mantenerse simples cuando apuntan solo a la visualización de la información espacial. La Figura 4.1 es un mapa web simple publicado en el sitio web de la BBC (Dunford et al. 2019).

Figura 4.1: Un mapa web simple: los resultados de las elecciones europeas en 2019 (Dunford et al. 2019).

A diferencia del mapa web anterior, el mapa interactivo Discover South Tirol ofrece una serie de herramientas y numerosas funciones cartográficas. Este es un mapa base topográfico que se combina con elementos y funciones de la API¹ de Google Maps (una captura de pantalla se puede ver en la Figura 4.2).

Figura 4.2: Mapa web interactivo: Discover South Tirol (captura de pantalla).

El requisito previo para el funcionamiento de los mapas web es un navegador web común. Para las aplicaciones de mapas web ya no es necesaria la instalación de un software especial, lo que simplifica significativamente el proceso. Sin embargo, la implementación exitosa de las aplicaciones depende en gran medida del diseño del mapa y de la simplicidad del uso del mapa. Como la mayoría de los usuarios no tienen conocimientos previos ni experiencia en el trabajo con SIG, el diseño del mapa debe permitir interacciones simples y fáciles de entender. El mapa web en sí debe centrarse solo en el propósito del mapa e incluir pocas funciones que se expliquen por sí mismas. Las soluciones predefinidas, aunque agilizan el proceso técnico del desarrollo, rara vez se ajustan a este nivel de simplicidad. Según Roth y Harrower (2008), Roth (2011) y Kraak (2018), la usabilidad de los mapas web se ha convertido en una ciencia.

4.1.1 Mapeo web y estándares OGC

Los estándares OGC juegan un papel secundario para los marcos de software propietario, como ArcGIS. Sin embargo, para el desarrollo de un WebGIS de código abierto (un sistema de servidor/cliente para datos espaciales), o para el intercambio de información entre diferentes softwares/sistemas o para incrustar mapas externos, los estándares OGC son esenciales. Aquí, presentamos una breve descripción general de los estándares OGC relacionados con el mapeo web.

4.1.1.1 Web Map Service (WMS)

El estándar Web Map Service (WMS) es probablemente el estándar OGC más conocido. WMS controla la visualización del mapa, incluidos los símbolos del mapa y las consultas de atributos, por lo tanto, es un componente clave de un mapa web. Están estandarizados los parámetros de solicitud, así como el formato de las respuestas.

Cada solicitud se construye de acuerdo con un esquema específico. Primero se define la operación, p.ej. ‘GetMap’², seguido de parámetros específicos: el nombre de la capa, el código para la proyección, las coordenadas del cuadro delimitador de la extensión del mapa, el ancho y el alto en píxeles de la salida del mapa (imagen), etc. Esta solicitud HTTP (en realidad una larga serie de letras, números y símbolos) se puede agregar en la barra de direcciones del navegador y se transfiere al WMS del servidor de mapas. Si todos los parámetros son correctos, entonces, la solicitud ‘GetMap’ recupera una imagen de mapa del área solicitada (respuesta).

Un WMS compatible OGC (es decir, un servicio de mapas web que cumple con los estándares del Open Geospatial Consortium – OGC) contiene dos funciones estándares y dos funciones opcionales que el usuario puede solicitar a través del protocolo HTTP:

• GetCapabilities: esta solicitud solicita las capacidades del WMS. La respuesta al usuario es un documento XML que contiene metadatos que incluyen los formatos compatibles con WMS del WMS y las capas que están contenidas en el mapa.

La sintaxis de la solicitud es

<--Server-URL-->?
  Service=WMS&
  Request=GetCapabilities&
  Format=application/vnd.ogc.xml

El documento de respuesta es legible por humanos, pero en realidad está destinado a ser interpretado por la aplicación de mapas (Figura 4.3):

Figura 4.3: Ejemplo de solicitud GetCapability³.

• GetMap: esta solicitud recupera las imágenes raster georreferenciadas del mapa. La solicitud puede tener consultas anidadas, como el número de capas del mapa, las opciones de visualización de las capas, el tamaño del mapa, la información del sistema de coordenadas, la extensión y el formato del mapa. Esta es la solicitud WMS más importante ya que recupera el mapa (imagen) en sí.

La sintaxis de la solicitud es

<--Server-URL-->?
  Request=GetMap&
  VERSION=1.1.1&
  SERVICE=WMS&
  SRS=EPSG:<--epsg-code-->&
  LAYERS=<--Name of layer-->&
  STYLES=&
  BBOX=<--coordinates of the bounding box-->&
  FORMAT=image/png&
  WIDTH=<--width of map output in pixels-->&
  HEIGHT=<--height of map output in pixels-->

• GetFeatureInfo (opcional): un WMS puede solicitar información sobre funciones en una ubicación específica de un mapa. La respuesta, generalmente una tabla HTML, es un extracto de la base de datos, como los valores de atributos para la capa del mapa y, opcionalmente, también su geometría (Figura 8.4). Esta solicitud está relacionada con el Servicio de características web (WFS) que consulta características individuales.

La sintaxis de la solicitud es:

<--Server-URL-->?
  Request=GetFeatureInfo&
  VERSION=1.1.1&
  SERVICE=WMS&
  SRS= EPSG:<--epsg-code-->&
  BBOX=<--4 coordinates of the bounding box-->&
  LAYERS=<--Name of Layer-->&
  WIDTH=<--width of map output in pixelswidth of map output in pixels-->&
  HEIGHT=<--height of map output in pixels-->&
  QUERY_LAYERS=<--name of layerL-->&
  X=<--x ordinate of query point on map-->&
  Y=<--y ordinate of query point on map-->&
  FEATURE_COUNT=<--number of features to return-->&
  INFO_FORMAT=<--output format of the feature information, e.g. text/html-->

Figura 4.4: Un ejemplo de respuesta a GetFeatureInfo: muestra un mapa de los cuerpos de agua de Tasmania. En el punto en el que se hizo clic (flecha roja) hay dos capas de mapa: ‘tasmania_water_bodies’ y ‘tasmania_state_boundaries’. El radio de búsqueda alrededor de la ubicación seleccionada es un estándar de 5 píxeles y se cruza aquí con 3 entidades poligonales: el estado de Tasmania y dos lagos. Para estas 3 características, todos sus atributos se recuperan y se muestran para cada capa del mapa

• GetLegendGraphic (opcional): Una consulta WMS puede devolver una imagen de la leyenda que se puede usar fuera del mapa y que incluye los símbolos y la descripción del mismo (ejemplo en la Figura 8.5). Para ello se debe habilitar el WMS “SLD”, es decir el estándar OGC para el estilo de leyenda “Styled Layer Descriptor” que hoy en día es algo común.

La sintaxis de la solicitud es

<--Server-URL-->?
  REQUEST=GetLegendGraphic&
  VERSION=1.1.1&
  FORMAT=image/png&
  WIDTH=<--width of map output in pixels-->&
  HEIGHT=<--height of map output in pixels-->&
  LAYER=<--Name of layer-->

Figura 4.5: Ejemplo de respuesta a GetLegendGraphic: la leyenda muestra las clases y la descripción de las mismas

Hungry minds

Si está interesado en obtener más información sobre este estándar:

• Eche un vistazo al tutorial WMS proporcionado por GeoServer.

• El OGC completo:Especificación de implementación de WMS que puede descargar aquí

4.1.1.2 Web Feature Service (WFS)

Web Feature Service (WFS) está directamente relacionado con WMS. Se requiere WFS cuando los usuarios desean acceder a entidades individuales y su geometría para editarlas y exportarlas. Este estándar es muy adecuado para la adquisición en línea de datos para mapas web a través de diferentes usuarios. Además, las capas del mapa se pueden exportar en diferentes formatos de datos (por ejemplo, como shapefile). WFS devuelve datos vectoriales en lugar de una imagen ráster. Aunque WMS recupera solo imágenes raster, puede importar datos vectoriales y raster.

Para que un WFS cumpla con el estándar OGC WFS, similar a WMS, se requiere un Protocolo de transferencia de hipertexto (HTTP). El WFS contiene seis operaciones:

• GetCapabilities (solicitud básica): esta solicitud consulta las capacidades del WFS. La respuesta es un documento XML con la información de los metadatos sobre el WFS, así como los tipos de características que se pueden solicitar y las posibles operaciones.
• DescribeFeatureType (solicitud básica): esta operación proporciona información sobre la estructura de los tipos de características individuales.
• GetFeature (solicitud básica): esta solicitud entrega las instancias de entidades individuales (es decir, los datos reales). Se deben especificar las propiedades de la entidad solicitada y si contienen información espacial.

La sintaxis de esta solicitud es

<--Server-URL-->?
  service=WFS&
  version=1.0.0&
  request=GetFeature&
  typeName=<--Name of layer-->&
  maxFeatures=<--max number of features to return-->&
  outputFormat=<--output format, e.g. shape-zip-->

• GetGmlObject (solicitud Xlink): el resultado de una consulta WFS es siempre un archivo GML. Con esta operación es posible recuperar por Xlink elementos individuales del archivo GML.
• Transaction (solicitud de transacción): Un WFS puede solicitar transacciones. Esto significa que las características de la base de datos se pueden cambiar, incluida la generación, actualización y eliminación de objetos.
• LockFeature: con esta solicitud WFS asegura que, durante una operación relacionada con una función, ningún otro usuario puede cambiar esta función.

Si WMS y WFS se utilizan dentro de la misma aplicación de mapas web (visor de mapas), no es necesario escribir las solicitudes HTTP antes mencionadas en la barra de direcciones del navegador. A través de cada interacción con el mapa (por ejemplo, zoom o desplazamiento), la aplicación combina automáticamente los parámetros y procesa los formatos devueltos. La configuración correcta, como URL del servidor, proyección, nombre de las capas, se requiere solo una vez.

Debido a que su rendimiento es más eficiente, es decir, la carga es significativamente más rápida, WMS es más adecuado para la visualización y solicitud de grandes volúmenes de datos. Con los ‘Styles Layer Descriptors’ (SLD) y las especificaciones de codificación de símbolos (SE), los usuarios pueden personalizar y visualizar las capas WMS y WFS para cumplir con sus requisitos (cartográficos).

4.2 Hungry minds

Si desea obtener más información sobre los SLD, puede consultar:

• GeoServer: Introduction a SLD, y
• GeoServer: SLD cookbook

4.2.0.1 Keyhole Markup Language (KML)

KML es el lenguaje que describe datos espaciales para los componentes de cliente de los mapas web. Originalmente, KML fue desarrollado para ser utilizado por y para Google Earth. En la actualidad, y desde que ha sido adoptado como estándar por el Open Geospatial Consortium (OGC), se utiliza para diversas aplicaciones de cartografía web. KML sigue la sintaxis XML y puede contener toda la información de la capa del mapa, como geometría, atributos (para contenido emergente) y estilos de leyenda. HTTP no puede solicitar los datos como un servicio, pero sigue el enfoque tradicional basado en archivos.

Aquí hay un documento KML de ejemplo y en la Figura 4.6 el resultado:

<?xml version="1.0" encoding="UTF-8"?>
  <kml xmlns="http://www.opengis.net/kml/2.2">
  <Placemark>
    <name>The Pentagon</name>
    <Polygon>
      <extrude>1</extrude>
      <altitudeMode>relativeToGround</altitudeMode>
      <outerBoundaryIs>
        <LinearRing>
          <coordinates>
            -77.05788457660967,38.87253259892824,100
            -77.05465973756702,38.87291016281703,100
            -77.05315536854791,38.87053267794386,100
            -77.05552622493516,38.868757801256,100
            -77.05844056290393,38.86996206506943,100
            -77.05788457660967,38.87253259892824,100
          </coordinates>
        </LinearRing>
      </outerBoundaryIs>
      <innerBoundaryIs>
        <LinearRing>
          <coordinates>
            -77.05668055019126,38.87154239798456,100
            -77.05542625960818,38.87167890344077,100
            -77.05485125901024,38.87076535397792,100
            -77.05577677433152,38.87008686581446,100
            -77.05691162017543,38.87054446963351,100
            -77.05668055019126,38.87154239798456,100
          </coordinates>
        </LinearRing>
      </innerBoundaryIs>
    </Polygon>
  </Placemark>
</kml>

Figura 4.6: El archivo KML anterior que se muestra en Google Earth.

Figura 8.6: El archivo KML anterior que se muestra en Google Earth.

4.2.1 Mapas web

Hay una diferencia entre la capa del mapa y el visor de mapas, que en realidad es la aplicación que muestra las capas del mapa. Ambos se denominan a menudo “mapas web”. Las imágenes raster son ampliamente utilizadas y son la parte principal de las capas del mapa web. Por lo general, una capa de mapa consta de teselas (tiles en inglés) que están disponibles en diferentes niveles de zoom y el nivel de zoom afecta la generalización de los datos. Por otro lado, un visor de mapas proporciona el “marco” en el que se incrustan más capas de mapas (mapas base o superposiciones temáticas). Los visores de mapas incluyen diferentes funcionalidades y elementos de navegación que permiten la interacción del usuario.

4.2.1.1 Capa base del mapa

Los proveedores comerciales como Google, Bing o Nokia (Here Maps) ofrecen una amplia variedad de capas de mapas base. Por lo general, tienen un precio de acuerdo con la cantidad de usuarios que acceden a los datos. Google Maps, por ejemplo, proporciona hasta 25 000 cargas de mapas por día de forma gratuita; este número incluye la actualización de los mapas al hacer zoom y desplazarse.

Una alternativa de código abierto igualmente difundida es OpenStreetMap (OSM), que se puede utilizar sin restricciones. La creación de un mapa base en línea como OSM requiere esfuerzos extremos (y la mayoría de las veces sin pago) y consta de varias capas agrupadas (por ejemplo, calles, casas, paradas de autobús y tren, área forestal, etc.). Los niveles de zoom para la visualización de estas capas varían entre 0 (mundo entero) y 19 (por ejemplo, bancos de un parque) y, en consecuencia, también su nivel de generalización. Por lo tanto, el mapa incluye solo una selección de objetos que se pueden mostrar claramente, junto con su etiqueta legible. Los objetos pequeños (p. ej., árboles individuales, casas) se pueden mostrar individualmente solo con niveles de zoom más altos y se muestran como un área más grande (bosque, área de asentamiento) a escalas más pequeñas. En un nivel de zoom más bajo, las líneas aparecen rectas (p. ej., ríos, costas).

Map Compare (por Geofabrik) permite la comparación en línea de 4 mapas base diferentes: OSM, Google, Satellite, Stamen Toner y HERE Terrsai - ¡Pruébelo!

Los mapas de OpenTopoMap se basan en OSM y un modelo de elevación digital. Hay una gran cantidad de servidores de teselas que brindan materiales de mapas: Stamen, por ejemplo, tiene un estilo de representación inusual (captura de pantalla en la Figura 4.7).

Figura 4.7: Los mapas web ‘Acuarela’ de Stamen también están basados ​​en OSM (desafortunadamente sin mostrar los nombres de las ubicaciones)

El desarrollo más reciente de los mapas base son las teselas vectoriales (vector tiles), en oposición a las teselas raster que se han utilizado exclusivamente hasta ahora. En este caso, en lugar de una imagen de trama preprocesada, los datos recuperados en las teselas son datos vectoriales. Las ventajas de las teselas vectoriales son el tamaño de volumen generalmente más pequeño de los datos vectoriales, así como su capacidad para permitir que un cliente edite los símbolos del mapa y ajuste la información mostrada. Desde julio de 2018, el mapa base vectorial de OpenStreetMap está disponible de forma gratuita en ArcGIS Online.

El Proyecto OpenMapTiles ofrece diferentes herramientas y mapas base vectoriales listos para usar para crear teselas vectoriales a partir de datos OSM con estilos individuales (por ejemplo, etiquetas específicas del idioma).

Mire este video en inglés que explica cómo crear teselas vectoriales usando ArcGIS Pro.

4.2.2 Desarrollo de Aplicaciones Web Mapping

Muchas aplicaciones de mapas web se basan en el principio mashup⁴ (mash=mixing), porque los mapas base en línea existentes, las capas de mapas temáticos y las funcionalidades predefinidas ya están combinadas. Los usuarios pueden usar plantillas de visor de mapas existentes o compilar sus propios elementos básicos.

Para diseñar y crear una aplicación de mapas web se puede elegir entre tres enfoques, teniendo en cuenta las especificaciones del producto final y el gasto de tiempo y recursos:

• Aplicaciones listas para usar (para contenidos simples, configuración de interfaz de usuario, generalmente se incluye alojamiento)
• Aplicaciones basadas en API (programación basada en bloques de código, no se requiere una base de datos propia, cantidad manejable de datos, generalmente se excluye el alojamiento)
• Aplicaciones WebGIS completas para Systemas Geodata-Server-Client (aquí se considera solo la aplicación de mapeo web desde la perspectiva del cliente)

Sin embargo, tenga en cuenta que no todas las soluciones se pueden clasificar en uno de los enfoques mencionados anteriormente, ya que algunas aplicaciones pueden sobreponerse.

4.2.2.1 Aplicaciones listas para usar

Varios proveedores ofrecen plataformas que en su mayoría incluyen servicios de alojamiento para mapas web simples sin que los usuarios tengan que vincularse a su propia base de datos. Además de los proveedores más grandes como Google Map (“Mis mapas” si tiene una cuenta de Google), también hay proveedores de plataformas más pequeñas que admiten el desarrollo de aplicaciones de mapas web, para las cuales no son necesarios conocimientos o habilidades de programación. Las plataformas más pequeñas no suelen ofrecer sus propios mapas, pero acceden a los mapas base de proveedores más grandes. Es muy difícil enumerar algunos ejemplos aquí, porque el mercado de las plataformas pequeñas es muy dinámico y los proveedores son bastante inconstantes. Estas aplicaciones listas para usar se denominan mapeo web 2.0 o mapas web generados por el usuario porque brindan opciones para publicar en línea información espacial fácil y sin esfuerzo; tenga en cuenta que estos mapas pueden quedar afectados por la falta de conocimiento y comprensión de los mapas por parte del usuario.

Le presentaremos algunas herramientas independientes adecuadas para el desarrollo de mapas web (la mayoría de ellas incluyen servicios de alojamiento) y todos pueden usarlas para publicar información espacial.

Sin duda Google Maps es el mapa web “tradicional” más popular. Con My Maps de Google y usando una cuenta de Google, uno puede crear y compartir un mapa fácilmente. Aquí hay un ejemplo de un mapa web creado con Google My Maps (la captura de pantalla se encuentra en la Figura 4.8).

Figura 4.8: Ejemplo de un mapa web creado con Google My Maps.

ScribleMaps es una alternativa para crear y compartir mapas propios y se puede elegir entre mapas base de OpenStreetMap, Google, Bing o ESRI.

MapTube no ofrece ningún servicio de alojamiento, pero si uno tiene su propio servidor web, también puede publicar sus propios archivos de forma (utilizando el software gratuito.

GMapCreator. Un ejemplo creado con MapTube es el mapa web ‘Cycling to Work’, donde se utiliza Google Maps como mapa base. Al hacer clic en un área, una ventana emergente enumera los atributos del shapefile (una captura de pantalla en la Figura 4.9).

Figura 4.9: Ciclismo al trabajo / un mapa web creado con MapTube

Las herramientas de mapas web integradas en el software SIG, como algunas extensiones (plugins) para QGIS, permiten el desarrollo de aplicaciones más complejas. Los usuarios familiarizados con el software QGIS pueden producir mapas efectivos con un esfuerzo limitado. Los proyectos de QGIS con capas y estilos de mapas son la base de aplicaciones completas de mapas web pequeños. Los siguientes 2 plugins de QGIS están disponibles:

• qgis2web
• QGIS Cloud

Qgis2web no proporciona ningún servicio de alojamiento, pero ofrece más opciones de diseño. Al contrario, las alternativas de visualización son limitadas en QGIS Cloud, pero los mapas web de QGIS Cloud se publican en un servidor web QGIS.

qgis2web

Este complemento convierte un proyecto QGIS en un archivo de datos HTML con archivos de datos JavaScript vinculados y los geodatos se guardan en formato GeoJSON. Los usuarios pueden elegir entre las dos API de mapeo web: OpenLayers y Leaflet. Aunque ambos tienen sus ventajas, vale la pena señalar que Leaflet ofrece la opción de agrupar datos de puntos y agregar los datos de puntos cuando se aleja (Figura 4.10).

Figura 4.10: Una captura de pantalla de un proyecto QGIS de un polígono y una capa de puntos. En la ventana de vista previa de qgis2web, los datos de puntos agrupados son visibles.

Tutoriales sugeridos para qgis2web

• Tutorial en Español:Mapeo Web con QGIS2Web por U. Gandhi
• Tutorial en Inglés: A Web Mapping Tutorial for Beginners por A. Sulce

QGIS Cloud

A partir de un proyecto de escritorio de QGIS, este complemento crea una infraestructura de datos espaciales (SDI) completa en la web, con la base de datos PostgreSQL-PostGIS. Las capas individuales se mostrarán en un cliente web de QGIS (QWC), pero también se pueden integrar en otras aplicaciones como WMS. En la Figura 4.11 puede ver un mapa web de QGIS Cloud publicado en un cliente web de QGIS.

Figura 4.11: Una captura de pantalla de un mapa web de QGIS Cloud publicado en un cliente web de QGIS.

Hungry minds

Guía de inicio rápido de QGIS Cloud

ArcGIS Online

Significativamente más elaborado está ArcGIS Online (AGO) de ESRI. El visor web de ArcGIS Online proporciona varios elementos SIG que se pueden combinar (p. ej., ventana de leyenda, tabla de contenido, función de zoom a entidad, etc.). Se centra principalmente en las funciones que permiten a los usuarios integrar sus propios contenidos (que pueden cargarse como archivos shapefiles) y combinarlos con la amplia variedad de datos que ofrece ESRI. Con una cuenta global de ESRI, los usuarios pueden crear, alojar y publicar/compartir mapas web en línea mediante un editor. Numerosas plantillas están disponibles para apoyar el diseño de un visor de mapas. Además, una “API de ArcGIS para JavaScript” adecuada puede extender individualmente una aplicación de mapas web para ArcGIS Online.

El mapa interactivo “Vulnerabilidad social de la malaria en África Oriental” (una captura de pantalla del mismo se encuentra en la Figura 4.12) es un ejemplo de la aplicación ArcGIS Online; se utiliza la plantilla de visor básico, se carga un shapefile y el diagrama muestra los atributos resultantes de una consulta.

Figura 4.12: Vulnerabilidad social de la malaria en África Oriental: un ejemplo de la aplicación ArcGIS Online (captura de pantalla)

Acerca de esta aplicación lista para usar recuerde:

• Ventajas: ESRI proporciona la infraestructura, muchas funcionalidades y herramientas (por ejemplo, diagramas para la visualización de los resultados de las consultas). La interfaz de usuario es fácil de entender, por lo que no requiere conocimientos ni habilidades de programación. No es necesaria instalación de software ni servidor propio.
• Desventajas: esta no es una solución de código abierto y depende en gran medida de una empresa. Su arquitectura apunta a utilizar otros productos de ArcGIS o servicios de ESRI para la preparación de los datos del usuario. Aunque ESRI intenta cumplir con los estándares de OGC, actualmente la implementación es limitada: p.ej. los datos de atributos de las capas de mapas WMS externas no se pueden consultar (es decir, la solicitud WMS ‘GetFeatureInfo’ no se admite actualmente). Por lo tanto, para OGC-Web Services (WMS, WFS), no se pueden usar datos externos o se prefieren las interfaces y el formato propios de ESRI.

GeoNode

Además de las soluciones propietarias, también existen aplicaciones WebGIS completas, configurables y de código abierto. Aunque estas opciones están disponibles de forma gratuita, también requieren más tiempo para la instalación y modificación de las aplicaciones hasta que los resultados sean satisfactorios. Dichos entornos generalmente no brindan servicios de alojamiento. Un ejemplo es GeoNode. En realidad, es un sistema de gestión de contenido que admite la adquisición, distribución y uso compartido de geodatos. GeoNode utiliza explícitamente varios softwares de código abierto como PostGIS y GeoServer. Debido a su interfaz de usuario amigable, incluso los usuarios sin experiencia en SIG pueden compartir datos y crear mapas interactivos.

Las capas de un mapa web se pueden importar en GeoNode. Los usuarios pueden elegir entre un grupo de capas ya existentes o pueden cargar sus propios datos (Figura 4.13). Los derechos de uso, descarga y edición se pueden asignar directamente tanto a usuarios individuales como a grupos.

Figura 4.13: Cómo cargar capas en GeoNode

Los usuarios pueden editar los datos de la capa, crear un estilo personal para mostrarlos, guardar y compartir el mapa final.

Ejemplos de aplicaciones de GeoNode.

• Ventajas de GeoNode: no se requiere experiencia en SIG para la preparación de datos y la creación de una leyenda de mapa. La combinación de los componentes de WebGIS en GeoNode es fácil de usar. Todos los elementos son OGC.

• Desventajas: La falta de una infraestructura de servidor (por ejemplo, como la que ofrece ArcGIS.com) es un problema para los usuarios privados. En comparación con otras soluciones propietarias, los datos disponibles aún son muy limitados, lo que también afecta la cantidad de estilos de capa predeterminados. En su mayoría, deben definirse usando CSS o SLD.

Aunque los usuarios pueden seleccionar y combinar de manera relativamente fácil y rápida los elementos individuales, casi no tienen influencia en la creación del visor de mapas. Y esta es la desventaja de las aplicaciones configurables listas para usar. No es posible incluir elementos adicionales (incluso información irrelevante para el mapa), como instrucciones paso a paso o consejos para usar herramientas, etc. Además, los usuarios no pueden resaltar por color ni pueden reducir el tamaño de las herramientas individuales y organizarlas en el mapa.

4.2.2.2 Aplicaciones basadas en API

Cuando, en lugar de aplicaciones listas para usar, uno comienza a buscar la modificación del código fuente, las funcionalidades del mapa y las opciones de diseño del mapa aumentan drásticamente. Tanto los proveedores comerciales (Google, Bing, etc.) como los de código abierto ofrecen las denominadas interfaces de programación de aplicaciones (API), que son códigos fuente que se pueden utilizar para el desarrollo de las propias aplicaciones de mapas web individuales del usuario.

Los códigos fuente que uno puede usar para desarrollar su propia aplicación de mapas web están en JavaScript. Este es el lenguaje de secuencias de comandos que, en general, se usa para animar sitios web HTML estáticos, respaldar la interacción del usuario y desencadenar una acción (por ejemplo, hacer clic en casillas de verificación, botones, listas desplegables, etc.). Dichas acciones podrían implicar el cambio de tamaño de las ventanas, el cambio de contenidos (por ejemplo, textos, imágenes…), la apertura de nuevas ventanas o, en el caso de la cartografía web, la incorporación de la extensión del mapa. Estas son acciones del lado del cliente, es decir, en el navegador en la máquina de los usuarios. Todos los cambios que hacen los usuarios se restablecen a la configuración predeterminada después de que los usuarios vuelven a cargar el sitio, a menos que la configuración se almacene en la máquina local mediante cookies.

La API permite la fácil implementación de funciones definidas por el usuario en una aplicación configurable lista para usar (como Google Maps) usando un código corto. Por ejemplo, es posible ver las coordenadas del mapa en una ventana emergente con solo hacer clic en el mapa; o para hacer zoom en una extensión de mapa predefinida pasando el cursor sobre un área específica. El propósito de estas soluciones rápidas con interfaces de programación es crear aplicaciones cartográficas web sencillas que incluyan mapas base y funcionalidades cartográficas. No están vinculados a geodatabases y, por lo tanto, los usuarios no pueden mostrar su propio contenido espacial (es decir, capas de mapas con símbolos de mapas propios) ni procesarlos de forma interactiva. En general, en el lado del cliente, las soluciones basadas en API se consideran una transición a las aplicaciones WebGIS basadas en bases de datos. Estos pequeños mapas web se pueden considerar como productos independientes o como entradas para proyectos más grandes, por lo que existen API de mapas web que se centran en ambos enfoques.

Se presentan brevemente algunas de las muchas API de mapeo web que ofrecen capacidades especiales de mapeo.

Comparación de las API de JavaScript de mapeo web

Existen varias alternativas y combinaciones, pero las API de JavaScript más utilizadas son la API Google Maps y Leaflet (para mapas web simples) y OpenLayer (para mapas web basados ​​en bases de datos más complejas).

La selección de una API depende principalmente del producto de mapa final y, a continuación, se enumeran los criterios que deben tenerse en cuenta:

• Disponibilidad de elementos básicos de navegación (y elementos con funcionalidad integrada, por ejemplo, botón de acercamiento) y que tan fáciles son de usar
• Habilidad para integrar y consultar información de bases de datos
• Compatibilidad estándar
• Qué tan fácil es entender y leer una API (código compacto y buena documentación)

Un beneficio adicional de las API comunes y de uso frecuente es que ya se conocen, por lo que hay numerosos ejemplos de código disponibles, así como foros de usuarios y buena documentación. Además, se espera la continuidad y un mayor desarrollo de estas API, en lugar de desaparecer de la noche a la mañana.

Hungry minds

Si desea obtener más información sobre las diferencias entre las API de mapas web, lea el siguiente artículo:

Top 19 geovisualization tools, APIs and libraries that will let you create beautiful web maps por A. Buczkowski (2016).

API de Google Maps

Dentro de las API de JavaScript disponibles comercialmente, una de las primeras (desde 2005) y con el rango funcional más amplio es la API de Google Maps. Google invierte significativamente en mapas base y actualmente ofrece una variedad de imágenes aéreas en 2D, 3D y 45°. Es compatible con GeoRSSFeeds, así como con los estándares OGC KML y WMS (sin embargo, WMS sin consultas de atributos) para la implementación de capas propias/externas. Google proporciona una buena documentación de tutoriales y ejemplos que permiten a los usuarios familiarizarse fácilmente con la API. Sin embargo, no es posible descargar y ajustar el código fuente.

Figura 4.14: Proyectos de Charity Water: un ejemplo de una API de Google Maps.

La Figura 4.14 presenta una captura de pantalla de un ejemplo de la combinación de la API de Google Maps con una capa de mapa propia y símbolos de mapa definidos por el usuario y agrupamiento de marcadores (al hacer zoom en el mapa, los símbolos se agrupan): The Charity Water projects.

OpenLayers

La API de código abierto más desarrollada es probablemente OpenLayers, que se lanzó por primera vez en 2006. A menudo se combina con el mapa base de OpenStreetMap, pero proporciona interfaces con varios servicios de mapas y formatos de datos. La API de OpenLayers es muy extendida, con más funcionalidades que la API de Google Maps y proporciona varios elementos de navegación personalizables. Funciones de edición, dibujo y medición, titulación del lado del cliente y conversión entre diferentes sistemas de coordenadas son algunas de las funciones que incluye.

La API de OpenLayers no es adecuada para aplicaciones pequeñas y rápidas porque es muy compleja; uno necesita tiempo para familiarizarse con ella y buenas habilidades de programación para poder trabajarla. Las geometrías deben construirse en capas vectoriales y esto puede ser un proceso engorroso. Por ejemplo, no existe ningún método para vincular una ventana emergente con un evento de clic, por lo que uno debe combinar varios bloques de código existentes individuales por su cuenta. Sin embargo, hay varias opciones diferentes disponibles para hacer esto. Los estándares OGC y la integración de bases de datos son una parte importante de la API de OpenLayers: es ideal para conectar la base de datos y el cliente mediante el llamado “middleware”, como el servidor de mapas compatible con OGC “GeoServer”. Debido a que OpenLayers proporciona opciones limitadas para modificar la interfaz de usuario, a menudo, y en particular para proyectos más grandes, se combinará con una API adicional de JavaScript para mejorar la interfaz de usuario. La documentación de OpenLayer no es muy completa, sin embargo, hay muchos ejemplos que pueden ser útiles.

OpenStreetMap es el ejemplo de aplicación más conocido de OpenLayers. Los resultados de las funciones de consulta se muestran en el lado izquierdo al hacer clic sobre la entidad en el mapa. (ver un ejemplo en la Figura 4.15).

Figura 4.15: Visualización de resultados de consultas en OpenStreetMap

API de ArcGIS para JavaScript 4.xx

La API de ArcGIS para JavaScript 4.xx proporciona un soporte eficiente para crear aplicaciones de representación cartográfica web que utilicen las funciones espaciales de la plataforma ArcGIS. Con ArcGIS API for JavaScript 4.xx puede crear aplicaciones que visualicen sus datos en 2D y 3D. Por ello, son necesarios conocimientos básicos de JavaScript, HTML5 y CSS. Basado en esta API es posible, por ejemplo, crear aplicaciones 3D interactivas. Para utilizar ArcGIS API for JavaScritp 4.xx, debe registrarse para obtener una suscripción gratuita de ArcGIS Developer. Además, tiene que incluir la atribución de ESRI en sus aplicaciones (ver más detalles sobre licencias).

Leaflet⁵

En 2011, CloudMade lanzó Leaflet, una de las API más recientes en comparación con otras API de código abierto, desde entonces, se volvió muy popular y está bien documentada. Sus capacidades no son tan completas como las de OpenLayer, pero esta API es más fácil de usar y se puede ampliar con complementos existentes, incorporando efectos simples y estéticamente agradables. Gracias a la estructura modular, el rendimiento de la API Leaflet es eficiente ya que utiliza solo el espacio de almacenamiento necesario. Leaflet, en combinación con otros mapas base gratuitos, es una buena alternativa para aplicaciones específicas más pequeñas. El formato de datos que utiliza Leaflet para las superposiciones (mapas temáticos) es GeoJSON (JavaScript Object Notation). El archivo GeoJSON contiene una “Colección de entidades” con información sobre geometría y atributos. Leaflet admite capas WMS con estilos definidos por el servidor, pero no la solicitud WMS GetFeatureInfo opcional para consultas de atributos. Las capas WFS no se pueden integrar.

Leaflet cluster map + choropleth (una captura de pantalla en la Figura 4.16) es un ejemplo de un mapa web de Leaflet. Aquí se agrupan los símbolos del mapa y se clasifican los polígonos.

Figura 4.16: Mapa de cluster y cloropletas en Leaflet

Sugerencia

Ogre de J.J. Patterson es una herramienta en línea para convertir shapefiles a archivos GeoJSON.

4.2.2.3 Aplicaciones WebGIS completas para sistemas de geodatos-servidor-cliente de fuentes abiertas

Las soluciones complejas de mapas web basadas en bases de datos que cumplen con OGC brindan la máxima flexibilidad de diseño posible. Se basan en una solución API (principalmente en OpenLayers) y se completan con una conexión a una base de datos. Pero una solución WebGIS de código abierto tan completa requiere tanto un servidor web como habilidades de programación avanzadas (Figura 4.17).

Figura 4.17: Arquitectura WebGIS, Cliente, Servidor y Datos

Debido a que los detalles sobre la tecnología MapServer van más allá del contenido de esta lección, nos centraremos en los componentes del cliente de WebGIS, es decir, la aplicación real de mapas web.

El objetivo de un WebGIS es permitir que los usuarios accedan a los datos que están almacenados en un servidor web a través de un cliente web. El WMS de código abierto se establece como el formato de intercambio entre el servidor y el cliente y con este estándar OGC, los usuarios pueden solicitar capas de mapas de todos los servidores compatibles con WMS. Los dos productos compatibles con el estándar OGC, PostGIS y GeoServer (el llamado “Middleware” que crea la capa WMS a partir de los datos espaciales en la base de datos) se pueden usar de manera similar al Boundless Server. Aunque debería ser posible integrar todas las capas WMS (independientemente del servidor en el que estén almacenadas, por ejemplo, incluso desde un ArcGIS Server), en realidad no se han implementado todos los estándares y, por lo tanto, algunas funciones estándar importantes (como la solicitud GetFeatureInfo para la consulta de atributos) son solo opciones disponibles.

El cliente envía una solicitud estándar OGC al servidor de mapas. El servidor de mapas “lee” los datos adecuados de la base de datos o de una fuente de datos basada en archivos (shapefile, GeoTIFF), asigna un estilo de leyenda y envía la respuesta estandarizada, es decir, la respuesta, al cliente (por ejemplo, una imagen de trama de la extensión del mapa solicitada y en la escala solicitada).

Como muestra la Figura 4.18, el componente principal de cada API de mapeo web es el “objeto de mapa”, que es responsable de la visualización del mapa. El servidor de mapas solo devuelve datos ráster o vectoriales estáticos y para la creación de un mapa interactivo, los nuevos datos deben ser solicitados repetidamente. Un “objeto de mapa” sirve como “traductor”: transfiere independientemente al servidor de mapas las consultas apropiadas (solicitudes) que se desencadenan por la interacción del usuario, en función del nivel de zoom y la extensión del mapa. Con cada acción (por ejemplo, acercar y desplazar) se crea una nueva solicitud con diferentes coordenadas y cada respuesta (por ejemplo, una imagen de trama) se mostrará en la aplicación.

Figura 4.18: El “objeto de mapa” se encuentra entre el Cliente y el MapServer y “traduce” una acción del usuario (aquí “panorámica”) en la Solicitud adecuada (ilustración de Mittlböck et al. 2012)

Las diferentes capas del mapa (mapas ráster y vectoriales) se integrarán en el “objeto del mapa” y definirán sus características, principalmente las proyecciones, el nivel de zoom de salida y la extensión del mapa de salida. De la misma manera que un API, un “objeto de mapa” también tiene diferentes funciones o “métodos”; esto significa que puede p.ej. “preguntar” acerca de su nivel de zoom (getZoom, consulta de estado) o “solicitar” una panorámica diferente (panTo, cambio de estado).

Ya hemos introducido algunas API de mapeo web. Para WebGIS exigentes se utiliza principalmente OpenLayers, ya que soporta todos los estándares OGC y el intercambio con el servidor de mapas “GeoServer” o “UMN Mapserver” funciona sin problemas. Sin embargo, al igual que todas las API de mapeo web, OpenLayers carece del diseño de la GUI.

4.2.2.4 Aplicaciones de interfaz de programación para WebGIS (GUI – APIs)

Para aplicaciones más grandes, las API de mapeo web de JavaScript ofrecen opciones limitadas para el diseño de GUI de un cliente web. Estas API no ofrecen elementos predefinidos que permitan la disposición jerárquica de las capas del mapa o permitan la visualización de las capas del mapa junto con gráficos de leyenda. Además, no proporcionan una herramienta que facilite el ajuste dinámico de la transparencia de una capa de mapa mediante una barra deslizante. Tampoco es posible mostrar los resultados de la consulta mediante diagramas. Para casillas de verificación adicionales, botones, listas desplegables, pestañas, etc., a menudo API de JavaScript adicionales, p.ej. ExtJS de Sencha o jQuery son necesarias.

WUEMoCA es un ejemplo de una aplicación de mapeo web creada por OpenLayers 3 y Sencha ExtJS 6 (para GUI). La Figura Figura 4.19 ilustra los diversos elementos que las 2 API crean individualmente: p.ej. la barra deslizante que se combina con el filtro de tiempo del mapa, los diagramas que muestran los resultados de las solicitudes ‘GetFeatureInfo’, o el selector de capas que, junto con la leyenda, se colocan en una ventana compacta que se puede arrastrar.

Figura 4.19: Elementos disponibles en WUEMoCA

Un enfoque más fácil que la combinación individual de API de mapeo y GUI-API usando Scripting, es de usar “Frameworks” y “Toolkits” predefinidos que permiten la combinación de componentes de código de una API de mapeo con componentes de código de una API GUI. El resultado es un nuevo componente compacto que el usuario no tuvo que crear por su cuenta. GeoExt combina OpenLayers y Sencha EXtJS. En dichos marcos, se pueden implementar herramientas como un árbol de capas o una barra deslizante para ajustar la transparencia.

En todos los paquetes predefinidos, la fácil implementación limita la flexibilidad del diseño. Las opciones son ilimitadas cuando los usuarios programan sus propios elementos en un código HTML y JavaScript, adicional a OpenLayers (o cualquier otra API de mapeo web). Por otro lado, las GUI-API ofrecen buenas características, incluido el diseño, y los usuarios no están obligados a programar la aplicación completa o al menos no el código base. Cuanto más complejo sea el marco, más difícil será aislar elementos individuales y ajustarlos en consecuencia. Otra desventaja de los marcos combinados es mantenerlos actualizados, una tarea difícil ya que las aplicaciones se desarrollan rápidamente. Poco después del lanzamiento de una nueva versión de un componente, es necesario ajustar el marco. Para los productos de código abierto, el ajuste puede llevar meses o incluso años.

4.3 Visualización dinámica

Ahora nos vamos a enfocar más en el aspecto dinámico de los mapas digitales. Antes de discutir las diversas categorías de visualización dinámica, nos gustaría explicar qué hace que las visualizaciones sean dinámicas. En pocas palabras, las visualizaciones se consideran dinámicas si se anima una variable o un elemento del mapa. La animación mejora la visualización en otra dimensión. Los mapas de coropletas, por ejemplo, se vuelven dinámicos al agregar una dimensión temporal, lo que potencialmente cambia la distribución espacial de los valores de los datos y la forma en que se muestran los datos. A menudo, los mapas se organizan de manera que la interacción del usuario desencadena cambios dinámicos en el mapa. Sin embargo, no todos los mapas interactivos pueden considerarse una visualización dinámica.

Revise el diagrama en la Figura 4.20 para tener una idea de las diferentes categorías de visualización dinámica.

Figura 4.20: Categorización de visualizaciones dinámicas (modificado de DiBiase et al. (1992) por Christoph Traun).

La lección 3: ‘Percepción y variables visuales’ introdujo las variables visuales. Al considerar la visualización dinámica, la lista de variables incluye mínimo 3 otras variables. Estas son: duración, tasa de cambio y orden.

La duración especifica cuánto tiempo se muestra una imagen durante la animación. Cuanto más corta sea la duración de cada imagen, más suave será la animación. Una duración de imagen de 8/1000 de segundo (aprox. 12 imágenes por segundo) se percibe como continuo. Dado que la duración es un valor cuantitativo, puede variar y ser proporcional a la magnitud de un atributo.

La tasa de cambio es simplemente la diferencia entre las imágenes (Figura 4.21). La tasa se puede basar en la ubicación del objeto o el valor de su atributo. Cuanto mayor sea la tasa de cambio, menos suave puede parecer la animación. Las altas tasas de cambio entre las imágenes deben combinarse con duraciones de visualización más cortas para que la animación parezca más fluida.

Figura 4.21: La tasa de cambio es una de las variables visuales adicionales de la visualización dinámica (según DiBiase et al. (1992) y Slocum et al. (2009)).

La secuencia determina la secuencia de las imágenes animadas. Si la animación es una serie temporal, la secuencia de imágenes sería cronológica. La secuencia también puede basarse en la magnitud de los atributos u otros criterios.

Además de las tres variables antes mencionadas, hay algunas otras opcionales, como el marco de tiempo (por ejemplo, el punto de inicio de la animación que representa una fecha específica), la frecuencia, los componentes acústicos (por ejemplo, el sonido: duración y volumen), las señales visuales y el ruido de fondo…

4.3.1 Casos de uso típicos

Crear una animación suele ser engorroso. Además, las animaciones no dan como resultado automáticamente un mapa más innovador ni comunican información de una mejor manera. Por lo tanto, es importante determinar primero si la visualización dinámica o la animación de una o varias variables brinda mejores resultados y vale la pena el esfuerzo.

Para crear animaciones, hay varias herramientas y formatos disponibles (p. ej., GIF animados, conjuntos de datos SVG, animaciones Flash, amplias bibliotecas de Java). También hay paquetes de software de modelado y visualización masivos que no se desarrollaron para crear animaciones de mapas, sino para fines de las industrias cinematográfica y cinematográfica y la ingeniería aérea y espacial.

La geovisualización dinámica es específicamente adecuada para los siguientes cuatro casos de uso, cada uno de los cuales analizaremos con más detalle a continuación:

1. Visualización de la dimensión temporal
2. Comunicación y presentación
3. Mapas dinámicos en tiempo real
4. Exploración interactiva de datos multidimensionales

Independientemente de la aplicación, la ventaja de utilizar animaciones es que las visualizaciones dinámicas siempre llaman la atención. En algunos casos, el aspecto dinámico de la pantalla contiene el mensaje principal que no sería visible sin la animación.

4.3.1.1 Dimensión Temporal

Los procesos geográficos siempre están incrustados en la dimensión temporal. Por tanto, propiedades espaciales como la configuración espacial o los atributos dependen del momento de la observación. Los mapas o visualizaciones estáticas generalmente no pueden representar visualmente la dimensión temporal. En estos casos, lo mejor es combinar una animación con controles interactivos.

Si se va a usar el tiempo como variable en la animación, entonces se debe considerar el tipo de escala de tiempo. En general, se puede distinguir entre escalas de tiempo lineales y cíclicas (Figura 4.22), mientras que las escalas lineales se dividen en escala cronológica (ordinal) o escala universal (intervalo). Las escalas cíclicas son patrones de tiempo que se repiten, por ejemplo estaciones, días de la semana, o el ritmo día/noche. Para cada caso, la escala de tiempo debe desarrollarse en consecuencia.

Figura 4.22: A diferencia de la dimensión espacial, el tiempo puede ser lineal o cíclico. La referencia absoluta para la dimensión temporal es el Tiempo Universal Coordinado (UTC)

El mapa debe diseñarse para que coincida con la escala de tiempo correspondiente. La leyenda juega un papel fundamental para definir claramente la escala de tiempo del mapa. La información de atributos de la leyenda es estática y debe tener una ubicación fija cerca del mapa animado. Las propuestas de Gapminder brindan una solución impresionante a este desafío. La interpretación visual de las animaciones es más fácil cuando la escala de tiempo se proporciona como información de audio: el ojo puede concentrarse solo en el contenido del mapa animado.

Además del tipo de escala, se debe definir el propósito final de la animación temporal. ¿Qué información puede obtener el usuario de la dimensión temporal? A continuación, se muestran tres casos de uso típicos:

• Proporcionar una visión general: informa al usuario sobre los cambios que se han producido a lo largo del tiempo. Puede filtrar información general, p.ej. las regiones del sur han experimentado un cambio en la población a lo largo del tiempo.

• Proporcionar un enfoque localizado: informa al usuario sobre los cambios en un área específica.

• Proporcionar un enfoque global: proporciona al usuario información sobre cambios a gran escala en la configuración espacial, p.ej. la aparición de grupos o puntos calientes cambiantes.

Dependiendo del propósito de la animación, los detalles pueden optimizarse para obtener el máximo beneficio. Esto incluye clasificación, agregación, esquemas de color o tasa de cambio.

4.3.1.2 Comunicación y presentación

Al incorporar visualizaciones dinámicas en las actividades de presentación y comunicación, generalmente se intenta mostrar la información en un entorno inmersivo tridimensional. El intento es mostrar la información de manera más realista y hacer uso de esta poderosa forma de comunicarse. En algunos casos se pueden aplicar conceptos de realidad aumentada.

Los modelos 3D del terreno o de la ciudad a menudo se visualizan dinámicamente durante los procesos de planificación y durante las presentaciones a las partes interesadas para brindar una mejor imagen de cómo los desarrollos futuros impactaran un área para una audiencia no especializada. En estos casos el nivel de detalle juega un papel importante.

Las animaciones que muestran fenómenos que son dinámicos por naturaleza son especialmente poderosas. Compare los dos mapas de las corrientes oceánicas globales a continuación. En la Figura 4.23, el fenómeno se muestra de forma estática mediante el uso de símbolos de mapas y otras técnicas cartográficas.

Figura 4.23: Representación estática del fenómeno dinámico de las corrientes oceánicas: solo imágenes de las corrientes en movimiento.

La animación del mismo fenómeno en el video (Figura 4.24) proporciona una dimensión y atracción extra.

Figura 4.24: VIDEO (3:02) NASA – Océano perpetuo

A continuación, algunos ejemplos más de animaciones y visualizaciones dinámicas:

• Mapas animados: Declive de Hielo en el Mar Ártico
• Peru-Chile: Terremoto y Tectonica
• Crecimiento de Walmart y Sam’s Club en EE.UU.
• Pared del cráter de Mojave (Marte) - Animación HiRISE DEM

Los simuladores de vuelo quedan estrechamente relacionados con las visualizaciones intuitivas de paisajes. En los simuladores, los aspectos geográficos de la posición y la dirección de la vista deben animarse dinámicamente. Estas aplicaciones van desde sobrevuelos de tipo turístico hasta simuladores de vuelo profesionales y de PC (incluidos videojuegos).

El objetivo general es proporcionar al usuario un entorno virtual realista. El nivel de interacciones entre el usuario y este entorno depende de la aplicación. Algunos ofrecen escenarios para sentarse y relajarse, mientras que otros permiten interacciones realistas, como la velocidad y los cambios de dirección.

En general, es importante no sobrecargar la visualización dinámica. Esto significa que deben evitarse los objetos decorativos animados (p. ej., objetos intermitentes y colores de fuente cambiantes).

4.3.1.3 Mapas dinámicos en tiempo real

Los mapas basados ​​en ubicación pueden mostrar información específica relevante para la situación/ubicación en la que se encuentra el usuario. Esto incluye la incorporación de datos en tiempo real en la información del mapa base mediante el uso de elementos dinámicos. Los sistemas de navegación, por ejemplo, pueden incorporar información de tráfico en tiempo real en su pantalla animada estándar (Figura 4.25).

Figura 4.25: Geovisualización en tiempo real.

Varios enfoques pueden proporcionar una solución a la incorporación de datos en tiempo real. Las aplicaciones basadas en JavaScript tienen la ventaja de que la página/el sitio no necesita ser cargada/o cada vez que se produce un cambio. Solo se actualizan los elementos dinámicos del mapa. JavaScript proporciona una mejora ideal para el estándar HTML5. Una opción adicional de incorporar datos en tiempo real es la generación de una imagen a través de un archivo KML o la actualización de información de la base de datos. Este enfoque es un poco más complejo porque se crea un elemento estático a partir de una fuente de datos en tiempo real y sería necesario implementar un intervalo de actualización específico.

También deben tenerse en cuenta las limitaciones perceptivas y cognitivas de la aplicación. Por ejemplo, la frecuencia de actualización debe ajustarse a la capacidad limitada del cerebro humano para reconocer cambios.

El mapa del metro de Londres en vivo (por Matthew Somerville) es un ejemplo de un mapa dinámico en tiempo real basado en JavaSript (aquí está el respectivo código JavaScript).

4.3.1.4 Exploración de datos multidimensionales

Mientras que los casos de uso anteriores se centraron en la comunicación de fenómenos espacio-temporales, la exploración de datos multidimensionales tiene el propósito de explorar datos y eventualmente descubrir nuevos fenómenos o patrones y relaciones sorprendentes.

La exploración se apoya de manera efectiva si la aplicación ofrece la posibilidad de aplicar filtros de forma interactiva, cambiar las escalas espaciales y temporales o adaptar la velocidad de la animación. El usuario ya no es un consumidor pasivo, sino un jugador activo en el tablero de datos.

Los mapas estáticos individuales difícilmente pueden mostrar datos multidimensionales, especialmente cuando el análisis incluye el aspecto temporal. En tales casos, las visualizaciones dinámicas son útiles. Por ejemplo, solo los mapas animados pueden mostrar la velocidad de grupos espaciales en movimiento.

El objetivo general de la exploración de datos es descubrir patrones y relaciones atributivas, espaciales y temporales; y es más fácil comprender los fenómenos subyacentes usando animaciones. Especialmente los cambios temporales y espaciales a gran escala (Detección de cambios) se pueden detectar mejor con visualizaciones dinámicas que en capas de mapas individuales.

4.3.2 Técnicas alternativas

Históricamente, las posibilidades técnicas para crear visualizaciones dinámicas eran muy limitadas. En el mundo de hoy, la potencia de las computadoras y los conjuntos de datos disponibles realmente no establecen una limitación. Las limitaciones cognitivas humanas impulsadas por las capacidades de trabajo y de memoria a largo plazo son las que deben tenerse en cuenta. Por lo tanto, la capacidad del usuario para procesar la información mostrada es de suma importancia. Esta capacidad varía según el grupo objetivo: desde personas familiarizadas con datos y técnicas de visualización hasta el público en general.

La memoria de trabajo de un cerebro humano puede tomar solo unos pocos fragmentos de información, mientras que nuestra memoria a largo plazo puede almacenar componentes de información mucho más complejos. Cada pieza de la información ingresa a nuestro cerebro desde la memoria de trabajo a la memoria a largo plazo, que luego se puede recordar. Esto significa que la información aprendida previamente se recuerda y se puede aplicar cuando se enfrenta a una situación similar, lo que a su vez conduce a un mayor aprendizaje.

Los aspectos importantes de la visualización dinámica en comparación con la visualización estática con respecto a la capacidad cognitiva son:

• La información solo se presenta durante un breve período de tiempo y no de forma permanente como en una pantalla estática
• La imagen anterior debe haber sido procesada en la memoria a largo plazo para poder detectar cambios.

El número de imágenes y la tasa de cambio son los principales parámetros que definen la eficiencia de una visualización dinámica. En algunos casos, es mejor mostrar los fenómenos dinámicos estáticamente o incorporar elementos estáticos. A continuación, discutiremos alternativas para una representación estática de datos dinámicos.

4.3.2.1 Visualización de rastros

Las visualizaciones de rastros son muy efectivas cuando se muestran posibles tendencias en los conjuntos de datos y no requieren procesos estadísticos complejos (Figura 4.26). Estos a menudo se combinan con animaciones temporales. Al mostrar los aspectos temporales, es importante que los valores de los datos anteriores permanezcan visibles, de lo contrario, es probable que la capacidad cognitiva humana no permita comprender la cantidad de información.

Figura 4.26: Gapminder permite el desarrollo de la visualización de rastros. En este ejemplo, las rutas muestran la evolución de los ingresos y la esperanza de vida entre 1800 y 2022 en Austria y Canadá.

La opción de rastros es adecuada cuando los valores de datos actuales deben ponerse en contexto con datos anteriores. Los valores de los datos se rastrean a lo largo del tiempo, por lo que los valores de los datos pasados ​​y presentes son visibles al mismo tiempo. Además, esta alternativa permite la identificación de valores atípicos.

4.3.2.2 Escala de tiempo

Cuando las visualizaciones se basan en una escala de tiempo, los valores de tiempo funcionan como un esquema que proporciona un orden (Figura 4.27). Los intervalos entre los valores de los datos son discretos y se diferencian por la visualización animada de los cambios en los datos. Esta opción es especialmente útil cuando se comunican fenómenos cronológicos que tienen una variable espacial fija. Según el propósito y el público objetivo, las escalas de tiempo pueden ser interactivas.

Figura 4.27: Una escala de tiempo hace referencia explícita a la dimensión temporal.

4.3.2.3 Prisma de espacio-tiempo

La visualización de datos espacio-temporales mediante el llamado prisma espacio-temporal (Figura 4.28) fue introducida por el geógrafo sueco Torsten Haegerstrand.

Primero, la representación planar espacial se organiza mediante un sistema de coordenadas x e y, luego se agrega el valor z que representa el tiempo. Esto permite la visualización de trayectorias, tiempo y espacio al mismo tiempo. El usuario puede obtener información sobre la velocidad de movimiento así como el lugar visitado o el tiempo de descanso.

Hay aplicaciones de software propietario (por ejemplo, GeoTime) y de código abierto (por ejemplo, el paquete RGL en R) disponibles para crear prismas de espacio-tiempo a partir de datos espacio-temporales.

Figura 4.28: Una trayectoria vista en un prisma de espacio-tiempo.

4.3.2.4 Pequeños múltiples

Cuando se visualizan datos espaciales a lo largo del tiempo, los cambios en el valor de los atributos suelen ser de interés. Como alternativa a la animación, el ‘pequeño múltiple’ puede proporcionar una solución. Esta opción muestra una serie de la misma extensión espacial con la información de atributos variable a lo largo del tiempo a intervalos fijos (Figura 4.29). Sin embargo, esto no muestra de manera integral los cambios a lo largo del tiempo, a menos que haya muchas instantáneas.

Figura 4.29: Una serie de imágenes en miniatura (‘pequeños múltiples’) admiten la comparación directa entre pasos de tiempo.

Los pequeños múltiples se hicieron populares a través del trabajo del estadístico Edward Tufte, sin embargo, las primeras visualizaciones de pequeños múltiples datan del siglo XVII.

Un ejemplo de pequeños múltiples son las distribuciones animadas de tornados de enero a diciembre que John Nelson publicó en su blog Tornado Migration: Visualizing Big Data Movement.

DiBiase, David, Alan M MacEachren, John B Krygier, y Catherine Reeves. 1992. «Animation and the role of map design in scientific visualization». Cartography and geographic information systems 19 (4): 201-14.

Dunford, Daniel, Paul Kirby, Paul Sargeant, Clara Guibourg, Ed Lowther, John Walton, y Irene de la Torre Arenas. 2019. «European election 2019: Results in maps and charts». BBC News. Retrieved from https://www. bbc. com/news/world-europe-48417191.

Kraak, MJ. 2018. «Evaluating Maps for Usability». ARCNews. https://www.esri.com/about/newsroom/arcnews/evaluating-maps-for-usability/.

Mittlböck, Manfred, Lucia Morper-Busch, Caroline Atzl, y Hermann Klug. 2012. «Task orientierte Web-Maps zur kompakten Visualisierung kartographischer Inhalte». En Beiträge zum 24. AGIT-Symposium in Salzburg, 333-38. Wichmann Verlag. http://gispoint.de/fileadmin/user_upload/paper_gis_open/537520060.pdf.

Roth, RE. 2011. «Interacting with maps: The science and practice of cartographic interaction». Tesis doctoral, The Pennsylvania State University. https://etda.libraries.psu.edu/paper/12433/7518.

Roth, RE, y M Harrower. 2008. «Addressing map interface usability: Learning from the lakeshore nature preserve interactive map». Cartographic Perspectives, n.º 60: 46-66. http://www.cartographicperspectives.org/index.php/journal/article/view/cp60-roth-harrower.

Slocum, Terry A., Robert B. McMaster, Fritz C. Kessler, y Hugh H. Howard. 2009. Thematic Cartography and Geovisualization. 1st Edition. Pearson.

---

1. API de Google Maps es una interfaz de programación de aplicaciones (API, por sus siglas en inglés) proporcionada por Google que permite a los desarrolladores integrar y utilizar funcionalidades de mapas y geolocalización en sus aplicaciones web o móviles.

2. La operación “GetMap” es una solicitud utilizada en el estándar de servicio de mapas web (WMS) para obtener una imagen de mapa del servidor WMS.

3. Una solicitud “GetCapabilities” es una solicitud utilizada en el estándar de servicio de mapas web (WMS) para obtener información sobre las capacidades y características del servidor WMS.

4. “mashup” es la combinación o fusión de diferentes fuentes de datos, servicios web o aplicaciones en una única aplicación o página web. Esencialmente, un mashup toma componentes de diferentes fuentes y los mezcla para crear una nueva funcionalidad o experiencia para el usuario.

5. Un curso gratuito denominado curso online “visores web mapping con Leaflet” puede encontrar aquí: https://mappinggis.com/cursos/aplicaciones-web-mapping-leafle ©MappingGIS. Y Un video en Youtube con acceso ¡GRATIS! de Geoportales - Introducción a Leaflet puede encontrar aquí: https://www.youtube.com/live/xxvOcFiXxT0?feature=share ©CAEG