SITMUN

La red europea SITMUN tiene como objetivo, entre otros, el desarrollo y mantenimiento de la plataforma SITMUN. Esta plataforma, abierta, de código libre con licencia EUPL v1.2, permite que las organizaciones supramunicipales que participan puedan ofrecer, a los municipios que coordinan, las aplicaciones de gestión territorial que estos municipios necesitan para su día a día. El despliegue, mantenimiento y actualización de estas aplicaciones está centralizado por la organización supramunicipal, de manera que los recursos de los municipios pueden focalizarse en prestar servicios a sus ciudadanos.

Esta web tiene como objetivo poner la documentación técnica de la plataforma SITMUN 3 a disposición de quienes participen en su desarrollo, en su implantación o en el desarrollo de aplicaciones que la utilicen.

Secciones de esta web

En la sección Cómo empezar se explica todo lo necesario para comenzar a trabajar con SITMUN 3. Podemos encontrar en ella:

• Los primeros pasos para comenzar a trabajar con SITMUN 3.
• La licencia de SITMUN 3.

En la sección Referencia se puede encontrar la documentación técnica de la plataforma SITMUN 3. Podemos encontrar en ella:

• La arquitectura describe desde un nivel de abstracción alto los principales elementos de la plataforma SITMUN 3.
• En la sección de diseño se describen aspectos técnicos de la plataforma SITMUN 3.
• En la sección de referencia se describen las API de la plataforma SITMUN 3 que están disponibles localmente durante el desarrollo.
• En la sección de gestión se describen aspectos organizativos y técnicos en lo que respecta al versionado, seguimiento del trabajo y automatización de procesos.
• La sección de contacto sugiere formas de contactar con los distintos participantes en el proyecto así como sus roles en el mismo.

Proyecto en desarrollo

SITMUN es un proyecto en continuo desarrollo y la documentación se actualiza para ir reflejando los cambios más importantes. Pueden existir algunas discrepancias entre la documentación y las últimas versiones del software. Si se detecta alguna discrepacia, notifícala en https://github.com/sitmun/community/issues/new.

Cómo empezar

¿Qué es SITMUN 3?

SITMUN 3 es una plataforma que permite la creación y gestión de aplicaciones personalizadas en el ámbito de los Sistemas de Información Geográfica (SIG). Está diseñada específicamente para satisfacer las necesidades de información territorial de las administraciones locales y supramunicipales.

SITMUN 3 ha sido desarrollado con la visión de proporcionar una herramienta de gestión de información territorial a los municipios, gestionada desde una entidad supramunicipal. Permite la integración de la información territorial con los datos de las corporaciones locales, independientemente del modelo de datos o del sistema de gestión de base de datos utilizado por cada municipio. Es importante destacar que SITMUN 3 agrega una capa de autenticación al acceso a los servicios cuando sea necesario, especialmente en consultas y siempre en los casos de gestión de información. Esta medida contribuye a la seguridad y privacidad de los datos, asegurando que solo usuarios autorizados puedan acceder y gestionar la información territorial

SITMUN 3 se presenta al usuario en forma de aplicaciones accesibles a través de visores de mapas, que se pueden configurar para que se adapten a las necesidades de cada municipio.

SITMUN 3 tiene una aplicación de administración que configura la información cartográfica, el territorio y las tareas que cada usuario tiene acceso para cada aplicación. Estas tareas ofrecen una amplia gama de funcionalidades, como consultas a bases de datos, generación de informes, buscadores, funciones de análisis espacial, entre otras.

SITMUN 3 dispone de una base de datos para administrar la plataforma. El modelo de datos permite la definición de información cartográfica, territorios, aplicaciones, tareas, usuarios, roles y permisos de acceso.

SITMUN 3 se basa en la utilización de servicios web estándar definidos por el Open Geospatial Consortium (OGC).

Todos los mensajes que se muestran en las aplicaciones de SITMUN 3 están parametrizados en un archivo de recursos disponible en varios idiomas.

SITMUN 3 tiene una arquitectura de 3 niveles:

• Nivel cliente: Actualmente, existen una aplicación de administración para los administradores y un visor de mapas basado en la API SITNA que es utilizado por los diferentes tipos de usuarios finales, tanto al público en general como a especialistas de los ayuntamientos, entre otros.
• Nivel de lógica de negocio: Desarrollado en Java con Spring Boot, tiene un modelo de entidades de Spring Data que refleja el esquema de la base de datos. El acceso a la lógica de negocio de los visores de mapas se realiza a través de la API de Configuración y Autorización (parte del SITMUN Backend) y de la API de Proxy (SITMUN Proxy-middleware). El acceso a la lógica de negocio de la aplicación de administración se realiza a través de la API de Administración (parte de SITMUN Backend). En ambos casos, los usuarios se autentican mediante la API de Autenticación.
• Nivel de datos: Puede estar en cualquier base de datos relacional, aunque actualmente se utilizan Oracle y PostgreSQL. El modelo de datos está documentado en la organización de SITMUN en GitHub.

La siguiente figura recoge el modelo descrito:

block-beta
  columns 5

  block:A:3
    columns 3
    admin["Aplicación<BR>de administración"]
    space
    viewer["Visor<BR>de mapas"]
  end
  space
  db4["Cualquier<br>servicio web"]

  space:5

  block:B:3
    columns 3
    backend["SITMUN<br>Backend"]
    space
    proxy["SITMUN<br>proxy-middleware"]
  end
  space
  db3["Servicio web<br>restringido"]

  space:5

  db1[("Base de datos<br>SITMUN")]
  space:3
  db2[("Cualquier<br>base de datos")]

  admin -- "Autenticación <br> + Administración" --> backend
  viewer -- "Autenticación <br> + Autorización <br> + Configuración" --> backend
  viewer -- "OGC API<br>+ Web API" --> proxy
  proxy -- "Autorización <br> + Configuración" --> backend
  backend --> db1
  proxy -- "Como<br>middleware" --> db2
  proxy --  "Como<br>proxy" --> db3
  viewer --> db4  

  classDef sitmun fill:yellow,stroke:#333;
  class admin sitmun
  class backend sitmun
  class viewer sitmun
  class proxy sitmun
  class db1 sitmun 

---

Siguiente paso: Requisitos

Requisitos

Antes de comenzar, asegúrate de cumplir con los siguientes requisitos:

• Una máquina Windows/Linux/Mac.
• Has instalado Git en tu máquina.
• Tienes un conocimiento básico de Git.
• Tienes acceso a internet en tu máquina para descargar repositorios de Git.

DockerWindowsLinux/Mac

• Al menos 4 GB de RAM.
• Soporte de virtualización (Hyper-V, KMV, WSL2, etc).
• Has instalado la última versión de Docker CE y Docker Compose, o Docker Desktop. Docker CE es totalmente de código abierto, mientras que Docker Desktop es un producto comercial.
• Tienes un conocimiento básico de Docker y Docker Compose.
• Tienes acceso a internet en tu máquina para descargar imágenes de Docker.

• Java 17 SE (LTS).
• Node.js. Puedes descargar Node.js desde el sitio oficial: https://nodejs.org/
  • Tanto el visor de mapas como el administrador requieren Node.js con una versión compatible con Angular 16, que debe ser >=16.0.0.
• npm: Puedes instalar npm siguiendo la guía oficial: https://docs.npmjs.com/cli/install
• angular cli: Una vez que hayas cumplido con los prerrequisitos mencionados anteriormente, procede a instalar el Cliente Angular de la siguiente manera:

  npm install -g @angular/cli
  

• Entorno de ejecución:
  • Al menos 1 GB de memoria.
  • Al menos 1 CPU.
  • Acceso a una base de datos soportada (PostgreSQL u Oracle) en el caso de backend.
• Si se va a instalar en Windows como servicio, se necesita además:
  • WinSW 2.12.0 o posterior
  • .NET Framework 2.0, 3.1, 4.0 o 4.6.1
• Se recomienda usar un proxy inverso delante del backend y del proxy (por ejemplo, IIS Microsoft) que sea capaz de proporcionar encabezados HTTP Forward (X-Forward u otros similares).

No olvides activar la ejecución de scripts de PowerShell

Es necesario permitir la ejecución de scripts de PowerShell. Para hacerlo, abre una consola de PowerShell con privilegios de administrador y ejecuta el siguiente comando:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

• Java 17 SE (LTS).
• Node.js. Puedes descargar Node.js desde el sitio oficial: https://nodejs.org/
  • Tanto el visor de mapas como el administrador requieren Node.js con una versión compatible con Angular 16, que debe ser >=16.0.0.
• npm: Puedes instalar npm siguiendo la guía oficial: https://docs.npmjs.com/cli/install
• angular cli: Una vez que hayas cumplido con los prerrequisitos mencionados anteriormente, procede a instalar el Cliente Angular de la siguiente manera:

  npm install -g @angular/cli
  

• Entorno de ejecución:
  • Al menos 1 GB de memoria.
  • Al menos 1 CPU.
  • Acceso a una base de datos soportada (PostgreSQL u Oracle) en el caso de backend.
• Se recomienda usar un proxy inverso delante del backend y del proxy (por ejemplo, nginx) que sea capaz de proporcionar encabezados HTTP Forward (X-Forward u otros similares).

---

Siguiente paso: Instalación

Instalación

DockerFuente

Pasos de instalación

Para instalar SITMUN, sigue estos pasos:

1. Clona el repositorio con submódulos y entra en el directorio:

   git clone --branch dev --recurse-submodules https://github.com/sitmun/sitmun-application-stack.git
   cd sitmun-application-stack
   

2. Prepara el entorno:

   • Linux/macOS:

   ./setup.sh
   

   • Windows:

   ./setup.ps1
   

3. Arranca la plataforma SITMUN:

   docker compose up -d
   

   Nota: Por defecto se utiliza PostgreSQL. Para usar Oracle:

   COMPOSE_PROFILES=oracle docker compose up -d
   

4. Verifica la instalación:

   docker compose ps
   curl http://localhost:9001/api/dashboard/health
   curl http://localhost:9002/actuator/health
   

5. Accede a las aplicaciones:

   • Visor: http://localhost:9000/viewer
   • Administrador: http://localhost:9000/admin
   • Backend API: http://localhost:9000/backend

   Credenciales por defecto:

   • Usuario: admin
   • Contraseña: admin

Servicios

Los servicios están definidos en el archivo docker-compose.yml. Los siguientes servicios están disponibles:

• front, un servidor web nginx en el puerto 9000 que publica la aplicación del visor de SITMUN (http://localhost:9000/viewer) y la aplicación administrativa de SITMUN (http://localhost:9000/admin) y enruta las solicitudes a los servicios backend (http://localhost:9000/backend) y proxy (http://localhost:9000/middleware)
• backend, que expone el API de autenticación, autorización y configuración de SITMUN (puerto 9001)
• proxy, que expone el API proxy-middleware de SITMUN y que se comunica con el servicio backend (puerto 9002)
• postgres: base de datos PostgreSQL 16 que almacena los datos en el volumen pgdata (puerto 9003)
• oracle: base de datos Oracle 23c alternativa (puerto 9004)
• example: base de datos PostgreSQL de ejemplo (puerto 9005)

block-beta
columns 5

space:2
front["<b>front</b><br>nginx<br>localhost:9000"]
space:2

space:5

postgres[("<b>postgres</b><br>PostgreSQL 16<br>SITMUN database")]
space:1
backend["<b>backend</b><br>Spring Boot<br>SITMUN backend"]
space:1
proxy["<b>proxy</b><br>Spring Boot<br>SITMUN proxy-middleware"]

front -- "/middleware" --> proxy
front -- "/backend" --> backend
proxy -- "/api/config/proxy" --> backend
backend -- "jdbc" --> postgres

Configuración

Las variables de entorno se definen en el archivo .env (si no existe, ./setup.sh copiará .env.example). Variables clave:

• COMPOSE_PROFILES: perfiles activos (postgres/oracle). Por defecto: postgres.
• DATABASE, DATABASE_URL, DATABASE_USERNAME, DATABASE_PASSWORD.
• FORCE_USE_OF_PROXY: fuerza el uso del proxy (false por defecto).

Desinstalación

Para detener y eliminar todos los servicios, volúmenes y redes definidos en el archivo docker-compose.yml, usa:

docker compose down -v

En desarrollo

Esta sección está siendo actualizada. Las instrucciones de instalación son un ejemplo de como serán en un futuro.

BackendProxyVisor de mapasAdministrador

Una vez completada la instalación de los prerrequisitos y la configuración, puedes proceder con la compilación del backend siguiendo estos pasos:

1. Descarga el proyecto https://github.com/sitmun/sitmun-backend-core en tu equipo.
2. Crea un proyecto nuevo a partir de las plantillas de la carpeta deploy y añádelo a settings.gradle.
3. Configura el fichero application.yml del nuevo proyecto. Ver Configuración.
4. Ejecutar el siguiente comando desde la raíz del proyecto en una terminal.

   ./gradlew clean :[proyecto]:build
   

   Este comando genera el fichero JAR del proxy en la ruta

   .[proyecto]/build/libs/[proyecto]-${version}.jar
   

Los sistemas operativos en los que se pueden desplegar el backend son:

• Linux: como servicio init.d, como servicio systemd o mediante un script de arranque.
• Windows: puede ejecutarse como un servicio Windows usando la herramienta WinSW o mediante un script de arranque.

Una vez completada la instalación de los prerrequisitos y la configuración, puedes proceder con la compilación del proxy siguiendo estos pasos:

1. Descarga el proyecto https://github.com/sitmun/sitmun-proxy-middleware en tu equipo.
2. Abre el proyecto descargado y modifica del fichero application.yml las propiedades security.authentication.middleware.secret y sitmun.config.url. security.authentication.middleware.secret debe contener el token que se ha configurado en el backend para que el proxy pueda autenticarse. sitmun.config.url debe contener la URI de la API de Configuración y Autorización del backend. Si el proxy y el backend son servicios internos de la misma red, se recomienda usar el nombre interno o la dirección IP interna del backend. Ver Configuración.

3. Ejecutar el siguiente comando desde la raíz del proyecto en una terminal.

   ./gradlew clean build
   

   Este comando genera el fichero JAR del proxy en la ruta ./build/libs/ con el nombre sitmun-proxy-middleware-[version].jar.

Los sistemas operativos en los que se pueden desplegar el proxy son:

• Linux: como servicio init.d, como servicio systemd o mediante un script de arranque.
• Windows: puede ejecutarse como un servicio Windows usando la herramienta WinSW o mediante un script de arranque.

El proxy middleware puede ser desplegado usando Docker. En la raíz del proyecto se encuentra la carpeta docker, en la cual se puede encontrar el fichero docker-compose.yml y el fichero Dockerfile.

Si se quiere desplegar únicamente el proxy, se puede hacer construyendo y arrancando la imagen del Dockerfile.

docker build -t sitmun/proxy-middleware .
docker run -p 8080:8080 sitmun/proxy-middleware

Como se ha comentado anteriormente, el proxy depende de la API de Configuración y Autorización y, por lo tanto, es importante tener correctamente configurada la URL a la API en el fichero de configuración (sitmun.config.url).

Es posible desplegar el proxy middleware en local sin necesidad de Docker mediante JVM ejecutando el siguiente comando en la ubicación del fichero JAR generado al construir el proxy.

java -jar sitmun-proxy-middleware-[version].jar

Una vez completada la instalación de los prerrequisitos puedes proceder con la compilación del visor de mapas siguiendo estos pasos:

1. Descarga el proyecto https://github.com/sitmun/sitmun-viewer-app en tu equipo.
2. Abre el proyecto descargado y modifica el parámetro apiUrl en el archivo environments.ts para que apunte a la URI donde está desplegado el backend. Ver Configuración.

3. Desde la consola de comandos, navega hasta el directorio raíz del proyecto y ejecuta el comando:

   npm ci
   npm build -- --configuration=<conf> --baseHref=<baseHref>
   

   Donde <conf> es la configuración y <baseHref> es la URI donde se va a desplegar. Este comando compilará el visor de mapas para el entorno de producción y generará los archivos en la carpeta dist/sitmun-viewer-app.

Para desplegar el visor de mapas en un servidor web, copia la carpeta sitmun-viewer-app a tu servidor web.

Configura tu servidor para redirigir las solicitudes de archivos no encontrados a index.html Es fundamental configurar correctamente esta redirección para el correcto funcionamiento del visor de mapas.

No olvides configurar la redirección a index.html en tu servidor

Si no se configura correctamente la redirección, es posible que la navegación dentro del visor de mapas funcione correctamente, pero al hacer clic en un enlace externo (por ejemplo, un enlace de correo electrónico), al introducir una URI directamente en la barra de direcciones o simplemente al refrescar la página, se produzca un error 404. Esto ocurre porque estas peticiones son manejadas directamente por el navegador y no por enrutador de Angular que gestiona la navegación dentro del visor de mapas. Ver Routed apps must fall back to index.html en la documentación oficial de Angular para más información.

Una vez completada la instalación de los prerrequisitos puedes proceder con la compilación del administrador siguiendo estos pasos:

1. Descarga el proyecto https://github.com/sitmun/sitmun-admin-app en tu equipo.
2. Abre el proyecto descargado y modifica el parámetro apiUrl en el archivo environments.ts para que apunte a la URI donde está desplegado el backend. Ver Configuración.

3. Desde la consola de comandos, navega hasta el directorio raíz del proyecto y ejecuta el comando:

   npm ci
   npm build -- --configuration=<conf> --baseHref=<baseHref>
   

   Donde <conf> es la configuración y <baseHref> es la URI donde se va a desplegar. Este comando compilará el administrador para el entorno de producción y generará los archivos en la carpeta dist/sitmun-admin-app.

Para desplegar el administrador en un servidor web, copia la carpeta sitmun-admin-app a tu servidor web.

---

Siguiente paso: Creando una aplicación

Creando una aplicación

Esta sección describe cómo crear y configurar una nueva aplicación en SITMUN 3.

Configuración básica

Para crear una nueva aplicación en SITMUN 3, sigue estos pasos:

1. Accede al administrador de SITMUN en http://localhost:9000/admin
2. Autentícate con las credenciales de administrador (usuario: admin, contraseña: admin)
3. Navega a la sección de Aplicaciones en el menú principal
4. Crea una nueva aplicación haciendo clic en el botón "Nueva aplicación"

Configuración de la aplicación

Información básica

• Nombre: Nombre descriptivo de la aplicación
• Descripción: Descripción detallada de la funcionalidad
• Tipo: Tipo de aplicación. En SITMUN están soportados tipos internos, externos y turísticos.
• Estado: Activa/Inactiva

Ajustes avanzados (opcionales)

• Privacidad: Marcar la aplicación como privada para restringir el acceso público (propiedad appPrivate).
• Parámetros de cabecera: Definir parámetros HTTP por defecto para las peticiones de la aplicación ("header parameters").
• SRS: Sistema de referencia espacial por defecto (srs).
• Escalas: Lista de escalas por defecto (scales).
• Mapa de situación: Grupo de cartografías de situación (situationMap).
• Autorefresco del árbol: Refrescar automáticamente el árbol de contenidos (treeAutoRefresh).
• Acceso por territorio: Habilitar acceso a territorios padre/hijo según necesidad (accessParentTerritory, accessChildrenTerritory).

Configuración de territorios

• Territorios disponibles: Selecciona los territorios donde estará disponible la aplicación
• Territorio por defecto: Establece el territorio por defecto para nuevos usuarios

Configuración de usuarios

• Roles permitidos: Define qué roles de usuario pueden acceder a la aplicación
• Usuarios específicos: Asigna usuarios específicos si es necesario

Configuración de capas

1. Añade capas cartográficas que estarán disponibles en la aplicación
2. Configura el orden de visualización de las capas
3. Establece la visibilidad por defecto de cada capa
4. Configura estilos y transparencias

Configuración de herramientas

1. Selecciona las herramientas disponibles en la aplicación
2. Configura parámetros específicos para cada herramienta
3. Establece permisos de acceso por rol de usuario

Pruebas y validación

1. Prueba la aplicación accediendo desde el visor en http://localhost:9000/viewer
2. Verifica la configuración de capas y herramientas
3. Comprueba los permisos con diferentes usuarios y roles

Despliegue

Una vez configurada y probada:

1. Activa la aplicación en el administrador
2. Notifica a los usuarios sobre la disponibilidad
3. Proporciona documentación de uso si es necesario

Consejos

• Comienza con una configuración simple y añade complejidad gradualmente
• Prueba siempre con usuarios de prueba antes del despliegue
• Mantén documentación actualizada de la configuración

---

Siguiente paso: Personalización

Personalización

Esta sección describe cómo personalizar y configurar SITMUN 3 para adaptarlo a las necesidades específicas de tu organización.

Configuración de la interfaz

Personalización visual

1. Logos y branding

   • Accede al administrador de SITMUN
   • Navega a la sección de configuración
   • Sube tu logo corporativo
   • Configura colores y estilos personalizados

2. Idiomas y localización

   • Configura los idiomas disponibles
   • Personaliza textos y mensajes
   • Ajusta formatos de fecha y números

Configuración de usuarios

1. Roles y permisos

   • Define roles personalizados
   • Configura permisos granulares
   • Establece restricciones por territorio

2. Autenticación

   • Configura integración con LDAP/Active Directory
   • Establece políticas de contraseñas

Configuración de datos

Bases de datos

1. Conexiones a bases de datos

   • Configura conexiones a bases de datos territoriales
   • Establece credenciales y permisos
   • Configura consultas personalizadas

2. Servicios de mapas

   • Añade servicios WMS/WMTS personalizados
   • Configura capas cartográficas
   • Establece estilos y simbología

Integración con sistemas externos

1. APIs y servicios web

   • Integra servicios OGC estándar mediante el proxy (WMS/WMTS/WFS)
   • Configura parámetros y cabeceras por defecto por aplicación

2. Sistemas de información geográfica

   • Conecta vía estándares OGC (WMS/WMTS/WFS) con ArcGIS Server y GeoServer
   • Configura capas y servicios compatibles OGC

Configuración avanzada

Rendimiento y escalabilidad

1. Optimización de consultas

   • Configura índices de base de datos
   • Optimiza consultas SQL
   • Establece caché de resultados

2. Configuración de servidor

   • Ajusta parámetros de memoria
   • Configura conexiones de base de datos
   • Establece timeouts y límites

Seguridad

1. Configuración de red

   • Establece reglas de firewall
   • Configura SSL/TLS
   • Implementa VPN si es necesario

2. Auditoría y logging

   • Configura logs de auditoría
   • Establece alertas de seguridad
   • Implementa monitoreo de acceso

Parámetros y privacidad de aplicación

1. Privacidad de aplicaciones

   • Marca aplicaciones como privadas para restringir acceso público

2. Parámetros de cabecera

   • Define cabeceras HTTP por defecto aplicadas a las peticiones de la aplicación

Herramientas de desarrollo

APIs personalizadas

1. Desarrollo de endpoints

   • Crea APIs REST personalizadas
   • Implementa servicios de negocio
   • Configura documentación OpenAPI

2. Integración con frontend

   • Desarrolla componentes personalizados
   • Configura temas y estilos
   • Implementa funcionalidades específicas

Testing y validación

1. Pruebas de integración

   • Configura entornos de prueba
   • Implementa tests automatizados
   • Valida configuraciones

2. Despliegue

   • Configura pipelines de CI/CD
   • Establece entornos de staging
   • Implementa rollback automático

Consejos de personalización

• Documenta todas las personalizaciones realizadas
• Mantén copias de seguridad de configuraciones
• Prueba cambios en entornos de desarrollo primero
• Considera el impacto en actualizaciones futuras

Ended: Cómo empezar

Características

Clientes

Visores de mapas

Aspectos globales

• Responsivo: Para entorno web y dispositivos móviles.

• Compatibilidad: Compatible con los navegadores más comunes.

• Autenticación: El cliente estará diseñado para utilizar solo HTTP sobre TLS (HTTPS). En caso de ser un visor público, el usuario ingresará directamente sin inicio de sesión. El cliente debe permitir la autenticación del usuario frente a la API de autenticación. La API responderá con el envío de un token JSON Web Token (JWT) que se utilizará para interactuar con la API de configuración y autorización y la API de Proxy.

• Inicio de sesión: Botón de inicio de sesión. El botón de inicio de sesión inicia el proceso descrito en la funcionalidad de autenticación, seguido, en caso de éxito, por la funcionalidad de configuración del cliente.

• Cierre de sesión: Botón de cierre de sesión. El botón de cierre de sesión borra el token de la aplicación, en caso de existir, seguido de la funcionalidad de configuración del cliente (en este caso, sin token).

• Multilingüe: Visualizadores multilingües (que puedan hacer solicitudes localizadas).

• Configuración de los clientes: El cliente se configura mediante una solicitud a la API de configuración y autorización. Si el usuario ha iniciado sesión, la solicitud debe incluir el token JWT obtenido de la API de autenticación. En caso de ser un visualizador público, la solicitud no incluirá un token. A partir de los datos de configuración (gestionados por la aplicación de administrador), el visor se configura para cada usuario, con los territorios y aplicaciones (capas y funcionalidades) a las que tiene acceso.

• Solicitudes a servicios remotos: Las solicitudes a algunos servicios remotos se realizan a través de la API de Proxy. Las solicitudes deben ir acompañadas de un token JWT, obtenido previamente de la API de autenticación, que identifica al usuario. La única excepción es el caso del usuario público, donde la autenticación es automática. Es decir, si no tiene una credencial, se asume que es el usuario público. Todas las solicitudes enviadas a través de la API de Proxy deben incluir, además, un identificador de territorio y un identificador de aplicación.

• Secuencia de inicio: el cliente solicitará a la API de configuración y autorización una configuración básica (idiomas, territorios, aplicaciones disponibles) para mostrar al usuario lo que puede seleccionar. El usuario podrá autenticarse frente a la API de autenticación, lo que restringirá los territorios y aplicaciones disponibles. Una vez seleccionado el idioma, territorio y aplicación, se iniciará la configuración del cliente frente a la API de configuración y autorización. La secuencia anterior se puede modificar en función de los parámetros pasados en la petición. Se puede restringir a una aplicación y territorio específicos e indicar que debe comenzar como visualizador público. Si se indica que debe comenzar como visualizador público, solo se pedirá al usuario que seleccione el idioma antes de pasar a la configuración del cliente.

Funcionalidades básicas de navegación

• Zoom con desplazamiento: Zoom dinámico con desplazamiento del ratón. Doble clic en el mapa para hacer Zoom-in.

• Pan: Botón derecho del ratón y arrastrar el botón.

• Barra de zoom: Barra deslizante vertical.

• Control de escala: Selector automático de nivel de escala.

• Zoom a ventana: Zoom a ventana (acceso rápido vía mayúsculas más ratón).

• Zoom de extensión: Botón de Zoom de extensión.

Funcionalidad de gestión de capas

• Orden de capas: Posibilidad de modificar el orden de visualización de las capas.

• Árbol de capas: Árbol de capas configurable para cada cliente a partir de la combinación de capas de diferentes servicios.

• Clasificación de capas: Opción para que el usuario pueda elegir entre diferentes árboles de capas previamente configuradas por el administrador.

• Transparencia: Control de la transparencia de las capas.

• Capas externas: Incorporación de capas externas (WMS, WFS, ATOM, GEOJSON, KML, SHP, ...).

• Metadatos: Botón con enlace a ficha de metadatos simplificados (extraídos dinámicamente del archivo XML de metadatos) con la opción de abrir en segunda instancia el XML completo de los metadatos.

• Leyenda: Consulta de la leyenda de la capa.

• Descarga: Enlace para descargar la capa (solo visible en caso de ser una capa descargable) y archivos relacionados (configurados en el administrador).

• Búsqueda de capas: Opción de buscar capas por nombre y descripción, en función del idioma del visualizador. Integrado con el buscador genérico.

• Mapa base: Selección del mapa base.

• Grupos de capas: Diferenciar entre capas y grupos de capas y permitir interactuar (visualizar, descargar, metadatos, etc.) con ambos elementos de la misma manera tanto para capas como para grupos.

• Capas activas: Ventana donde se presenten todas las capas activas, tanto las activadas desde el árbol como las cargadas de manera externa.

Herramientas básicas

• Imprimir: Impresión configurable del mapa, la leyenda, el gráfico, el título, el norte, logotipos, etc.

• Medición y dibujo: Integración de herramientas de medición de áreas, distancias y coordenadas de un punto con las de dibujo de elementos sobre el mapa.

  • Modificar la simbología del elemento dibujado.
  • Imprimir los elementos dibujados al imprimir el mapa.
  • Creación de perfiles del terreno de las líneas medidas.
  • Guardar localmente los elementos dibujados en formato KML.
  • Generar enlace para compartir el mapa con los elementos dibujados.
  • Posibilidad de añadir textos sobre el mapa.

• Obtener posición: En caso de estar disponible en el dispositivo, botón para obtener la posición del usuario.

• Leyenda: Ventana que muestra la leyenda construida de manera dinámica para todas las capas activas.

• Portapapeles: Copia fácil del mapa y/o la leyenda y/o el gráfico al portapapeles.

• Pantalla completa: Posibilidad de poner el visualizador en modo de pantalla completa.

Información

• Información: Botón para solicitar información alfanumérica de los elementos gráficos de las capas activas (información y más información actual). Formatea la tabla de respuesta por defecto con una apariencia atractiva, clara y amigable para el usuario, y presentar imágenes y enlaces por defecto. Hay opción de organizar la información en pestañas. Es importante poder personalizar las ventanas de información en función de cada capa, más allá de especificar el tipo para cada campo (foto, texto, URL, etc.), tal y como permite ahora el acceso al código de cada tarea.

Buscadores, consultas y selección espacial

• Buscador básico: Búsqueda de topónimos básica integrada con el buscador de capas. Muestra candidatos a partir del tercer carácter y diferencia en la lista entre topónimos y capas.

Herramientas avanzadas

• Compartir: Posibilidad de compartir el mapa de diferentes maneras:

  • A través de un enlace.
  • A través de un IFRAME configurable con las capas activas en el momento de generar el IFRAME y en el que se pueda hacer GetFeatureInfo de las capas y algunas herramientas básicas (cambiar el fondo del mapa).
  • Enlace a redes sociales (Twitter, Facebook).
  • Generar código QR.

• WMC: Posibilidad de guardar el WMC (vinculado a la funcionalidad anterior).

• Operaciones espaciales: Posibilidad de realizar operaciones espaciales entre capas como la intersección espacial aplicando un buffer.

Otras herramientas

• Streetview: Herramienta para agregar Street View al mapa.

Aplicación de Administración

Documentación en desarrollo

Canonical Link References

• API de autenticación
• API de configuración y autorización
• API de Proxy

Servidores

API de Autenticación

• Proporcionar token de acceso JSON web token (JWT) que permite al usuario acceder a los servicios de la plataforma.

• Autenticación local. SITMUN almacena las contraseñas de los usuarios en la base de datos SITMUN usando un hash criptográfico (bcrypt).

• Autenticación LDAP. Está soportado la autenticación a través de un servidor LDAP.

• Verificación de usuarios. Endpoints para verificar contraseñas y disponibilidad de email.

• Recuperación de contraseña. Sistema de recuperación de contraseña por email con tokens seguros.

API de Configuración y Autorización

• Proporcionar configuración a clientes. Proporciona la configuración necesaria para que el visor de mapas se configure para cada usuario, con los territorios y aplicaciones (capas y funcionalidades) a las que tiene acceso.

• Proporcionar configuración al proxy. Proporciona la configuración necesaria para que cada petición realizada al proxy se configure para cada usuario, en función de la aplicación y el territorio seleccionados. La petición deben autenticarse usando una API key enviada mediante la cabecera denominada X-SITMUN-Proxy-Key.

• Filtrado transparente. Al configurar un proxy, se pueden añadir adicionalmente parámetros de filtrado basados en el identificador del usuario, el identificador de la aplicación, y los identificadores del territorio. Estos parámetros de filtrado se añaden a la petición que se realiza al servicio o base de datos final por parte del proxy. Estos parámetros se gestionan mediante la API de Administración indicando como valor una de las siguientes variables: $USER_ID, $APP_ID, $TERR_ID y $TERR_COD.

API de Administración

• Gestión de usuarios. CRUD completo de usuarios con roles y permisos.

• Gestión de territorios. Administración de territorios y sus configuraciones.

• Gestión de aplicaciones. Configuración de aplicaciones y sus funcionalidades.

• Gestión de tareas. Configuración de tareas y herramientas disponibles.

• Gestión de capas. Administración de capas cartográficas y servicios.

• Pruebas de conexión. Herramientas para probar conexiones a bases de datos.

• Extracción de capacidades. Herramientas para extraer capacidades de servicios OGC.

• Extracción de tipos de entidad. Herramientas para extraer información de tipos de entidad.

API de Proxy

Aspectos globales

• Gestión de servicios transparente: Las peticiones a los servicios externos y consultas a bases de datos son realizadas a través del proxy sin que el usuario conozca los datos que componen la solicitud al servicio o conexión a base de datos.

• Adaptación transparente. Las peticiones se adaptan en función de la aplicación, el territorio y el usuario.

• Personalizado. La petición pueden autenticarse usando un esquema de autenticación por portador (Bearer authentication) usando un token que se ha obtenido previamente mediante la API de Autenticación. Si no se autentica, se asume que la petición se ha realizado por un usuario que en el dominio de SITMUN se denomina usuario público.

• Modificación de peticiones: Posibilidad de manipular la petición de varias formas para que se adapte a la configuración obtenida de la API de configuración y autorización.

Servicios soportados

• Servicios OGC Web Map Service (WMS), que ofrecen mapas en formato imagen usando peticiones HTTP GET.

• Servicios OGC Web Map Tile Service (WMTS), que proporcionan mapas divididos en teselas (tiles) usando peticiones HTTP GET (codificación KVP).

• Servicios OGC Web Feature Service (WFS), que permiten el acceso a datos geoespaciales vectoriales usando peticiones HTTP GET (codificación KVP).

• Bases de datos relacionales que dispongan de un controlador (driver) JDBC (Java Database Connectivity). Las respuestas de las bases de datos se devuelven en formato JSON usando peticiones HTTP GET.

Modificadores generales

• Parámetros (Servicios): Modificador encargado de añadir a la petición los parámetros proporcionados por el visor y la API de configuración y autorización. La API de configuración y autorización puede haber añadido parámetros a la petición que el visor no ha proporcionado (por ejemplo, parámetros de filtrado).

• Autenticación de acceso básica (Servicios): Modificador encargado de incluir en la cabecera de la petición HTTP un usuario y contraseña si fuese necesario (RFC 7617).

• Selección (JDBC): Modificador encargado de crear la conexión con base de datos con los datos proporcionados por la API de configuración y autorización.

• Filtrado (JDBC): Modificador encargado de incluir filtros en la consulta.

Hoja de ruta

Proyectos

Última modificación	Junio 2025
Próxima modificación	Diciembre 2025

¡Bienvenido a la hoja de ruta de SITMUN 3! Estas son las prioridades del equipo SITMUN.

El objetivo de esta hoja de ruta es ofrecer una visión general del estado del proyecto SITMUN 3 y las próximas funcionalidades a desarrollar.

Aspectos generales

El Comité Técnico de SITMUN es el órgano funcional encargado de revisar la descripción o, en su defecto, describir el alcance funcional de cada uno de los puntos. También de proponer la priorización de cada uno de los proyectos o funcionalidades.

Durante la Asamblea Ordinaria Anual de socios del proyecto SITMUN se vota y aprueba la priorización.

Proyectos en desarrollo

Proyecto - Funcionalidad	Descripción	Estado
Aplicación SITMUN para dispositivos móviles de edición gráfica y alfanumérica. APP SITMUN Edición	Este proyecto busca dotar a la plataforma SITMUN de una herramienta para dispositivos móviles (Android) que permita la edición offline de objetos geográficos y alfanuméricos, basada en servicios web estándard, con control de acceso de usuario, definición de permisos, que pueda ser administrada desde el Administrador SITMUN 3, como un cliente más. Ver detalles aquí.	En desarrollo (inicio noviembre 2024)
Aplicación SITMUN para dispositivos móviles orientada al turismo APP Turismo	Este proyecto busca dotar a la plataforma SITMUN de la capacidad de disponer de una aplicación turística para dispositivos móviles (Android e iOS) común para todos los territorios que usen SITMUN como plataforma y cuyo contenido y funcionalidad pueda gestionarse desde el administrador SITMUN 3, como un cliente más. Ver detalles aquí.	En desarrollo (inicio noviembre 2024)
Mejora de la página de acceso a la plataforma SITMUN	Mejorar la interficie de la ventana de login a los clientes SITMUN disponibles para el usuario así como el dashboard para la selección de aplicación, territorio y configuración de opciones y datos de usuario. Ver detalles	En desarrollo Análisis previo y propuesta técnica de implementación.
Creación dinámica de informes	Posibilidad de generar un informe (report) de forma dinámica desde un el cliente SITMUN, que haya sido previamente configurado en el administrador SITMUN 3. Un informe se configura en SITMUN como una tarea que integra el resultado de otras tareas. Ver detalles aquí	En desarrollo Análisis previo y propuesta técnica de implementación.

Proyectos prioritarios

Proyecto - Funcionalidad	Descripción	Prioridad
Edición gráfica y alfanumérica	Integrar en el cliente SITMUN 3 API SITNA la herramienta de edición disponible en el API SITNA. API SITNA	Alta
Más info	Implementar en el cliente SITMUN 3 API SITNA la capacidad de interpretar y ejecutar tareas más info definidas como tal en el administrador SITMUN 3. Asimilando el funcionamiento al de los actuales clientes SITMUN 2. Ver detalles aquí.	Alta
Localizadores	Implementar en el cliente SITMUN 3 API SITNA la capacidad de interpretar y ejecutar localizadores definidos como tareas en el administrador SITMUN 3.	Alta
Consultas	Implementar en el cliente SITMUN 3 API SITNA la capacidad de interpretar y ejecutar consultas definidas como tareas en el administrador SITMUN 3. Asimilando el funcionamiento al de los actuales clientes SITMUN 2.	Alta

Cola de proyectos (sala de espera)

Proyecto - Funcionalidad	Descripción	Prioridad
Creación de un cliente SITMUN - API CNIG	Creación de un cliente SITMUN3 basado en el API CNIG	Media
Creación de temáticos	Dotar al cliente SITMUN 3 de una funcionalidad que permita al usuario modificar la simbología de una capa en función del valor de sus atributos.	Baja

Proyectos finalizados

Proyecto - Funcionalidad	Descripción
Publicación SITMUN3 v1.0.0	Publicación de la primera versión estable de SITMUN 3 y la organización del repositorio de Github y la creación de un stack que facilite la instalación y creación de un entorno de desarrollo.
Múltiples árboles de capas	Extender la funcionalidad de API SITNA para poder vincular más de un árbol a un cliente SITMUN
Comparación de mapas de fondo	Extender la funcionalidad de API SITNA para poder implementar dos mapas de fondo en la tabla de contenidos y una barra de transparencia entre ellos.
Arbol de capas	Extender la funcionalidad de API SITNA para permitir la configuración de una estructura de árbol de capas definida desde el administrador, a partir de la atomización de servicios OGC y la configuración de las distintas capas que los conforman en nodos y subnodos.
Autorización por token en el cliente	Permitir la autenticación por token en el cliente SITMUN 3 API SITNA.
Actualización versión Angular	Actualización del administrador SITMUN a la última versión de Ángular y refactorización del código.
Creación de página web del proyecto (e imagen corporativa)	Creación de una página web de difusión del proyecto y actualización de la imagen corporativa
Creación de página de documentación	Creación de una página web de documentación del proyecto SITMUN 3 que facilite el seguimiento del proyecto, la comprensión tecnológica de la plataforma y facilite el el uso y la participación en los desarrollos (contibuciones de código)
Desarrollo cliente visualizador SITMUN 3 (Integración API SITNA)	Creación de un cliente SITMUN3 basado en el API SITNA que se configure de forma dinámica a partir de la respuesta JSON que proporciona la API Rest del backoffice de SITMUN
Desarrollo del Administrador SITMUN 3	Desarrollo de una herramienta de administración SITMUN que permita la configuración de múltiples visualizadores de mapas SITMUN a partir de la definición de contenidos y la gestión de permisos de usuario
Desarrollo del nivel intermedio SITMUN 3 (Backoffice y Proxy middleware)	Desarrollo de las API de Configuración y Autorización, la API de Proxy, la API de Administración y la API de Autenticación
Diseño de base de datos SITMUN 3	Revisión e internacionalización de la base de datos de SITMUN 3

Ended: Hoja de ruta

Propuestas

Más info avanzado

Aspectos generales

Estimación horas de desarrollo: 200 horas

Entidad solicitante: Comisión técnica SITMUN

Prioridad: ALTA

Persona o entidad de referéncia o contacto: Consell Insular de Menorca

Objetivo

Esta funcionalidad busca dotar a SITMUN 3 de la capacidad de configurar, desde el administrador SITMUN 3, el contenido de la ventana que devuelve el visor SITMUN 3 al realizar una consulta sobre el mapa para una capa determinada.

El contenido de la ventana debe poder integrar la respuesta de una o varias consultas definidas como tareas al propio administrador

Contexto y casos de uso

El actual cliente SITMUN 3, al hacer clic en el área de mapa sobre un objeto de una capa determinada, presenta el resultado de la petición GetFeatureInfo sobre al servicio WMS correspondiente.

Con la funcionalidad 'Más info avanzado' se busca enriquecer esta ventana de respuesta con datos que provengan de otras peticiones a otros servicios o conexiones a base de datos.

Como ejemplo se puede observar el funcionamiento de SITMUN 2 en el caso del visualizador de medio natural del Consell Insular de Menorca. En la ventana siguiente podemos observar el detalle de la ventana con distintas pestañas, cada una de ellas se corresponde con el resultado de una tarea de tipo consulta configurada en el administrador SITMUN 2.

Actual ventana de ejemplo de configuración de una tarea tipo consulta en SITMUn 2.

Requerimientos funcionales

Se prevé la siguiente lógica funcional:

1. En el administrador SITMUN 3 se definirán primero las distintas tareas (que pueden ser de distintos tipos consultas a bases de datos, consultas a servicios, …) que formaran parte de la ventana de más info avanzado.

   Por ejemplo, en el caso del visor medioambiental anterior, se establecen varias consultas:

   • Una primera tarea que consiste en consulta que devuelve toda la información relativa a una ruta turística:

   

   • Una segunda consulta que devuelve todas las fotografías de una ruta en concreto:

   

2. Una vez definidas estas tareas, que llamaremos tareas hijas, se configurarà en el administrador SITMUN la tarea padre más info avanzado En la ventana de configuración de dicha tarea se podrá:

   • Establecer la relación con las distintas tareas hijas que forman parte del más info avanzado. Una tarea hija, a su vez, debe poder formar parte de varias tareas padre.
   • Establecer el tipo de más info avanzado, para establecer cómo se presentarán en la ventana las distintas tareas hijo (en tabs, en scroll…)

   

   • Establecer para cada tarea hija el código HTML con la configuración o formato de renderizado (para poder definir la tabla, o cómo se muestran las imágenes, o una galeria de fotos, etc.). A este código se añadirán marcas especiales con el nombre de los campos de la subconsulta que serán sustituidas en el cliente (API SITNA) por el valor de los mismos. Por ejemplo, a la tarea hija código 289 (primera imagen del visor de medio ambiente) le corresponde este layout, dónde los valores @@CODIGOTAREA_NOMBRECAMPO@@ deben de ser sustituidos por el valor del campo correspondiente a la consulta 289.

     

   • Definir qué capa o capas tienen asociada esta funcionalidad.

   • Definir qué territorios y roles de usuario tienen asociada esta funcionalidad.

3. Configurada correctamente la tarea, la API de configuración y autorización_ deberá incorporar los valores necesarios para permitir al cliente SITMUN 3 - SITNA (1) detectar qué capas tienen un más info avanzado definido (para el rol y territorio que esté logeado). Así mismo, la API deberá retornar la información necesaria y suficiente para que el cliente (API SITNA u otros) puedan renderizar la información consultada de forma adecuada.

4. El Cliente SITMUN - API SITNA deberá configurar correctamente la ventana de info cuando se realice un clic sobre el mapa a un elemento de dicha capa, en caso de que la capa tenga asociada una tarea de esta índole.

   El cliente permitirá gestionar el comportamiento en caso de que el usuario haga clic a dos o más objetos sobre el mapa pertenecientes a la misma capa y/o a distintas capas, algunas de las cuales pueden tener una funcionalidad más info avanzado* definida y otras no (con lo que presenta la ventana por defecto de respuesta GetFeatureInfo).

Se identifican los siguientes requerimientos funcionales a desarrollar para cada uno de los componentes de la arquitectura de SITMUN:

Cliente Administrador

Funcionalidad	Commit messages	Issues relacionadas
Posibilidad de configurar tareas SITMUN de consultas a base de datos	Existente no testeada
Posibilidad de configurar tareas SITMUN de consulta a servicios web	Existente no testeada
Creación de tipo de tareas padre que permitan seleccionar tareas hijo con una vinculación N a M	Nueva
Asignación de parámetros específicos a tareas padre Tab scroll	Nueva
Asignación de una respuesta avanzada a una capa existente	Nueva

Cliente visualizador (API SITNA)

Funcionalidad	Estado	Issues relacionadas
Parsear json del API de configuración y representar los datos	Existente no testeada
Gestionar y renderizar la configuración de la respuesta avanzada para una capa concreta	Nueva

API de autenticación

No se prevén modificaciones dea este componente durante el desarrollo de esta funcionalidad.

API de administración

Funcionalidad	Estado	Issues relacionadas
Posibilidad de configurar tareas SITMUN de consultas a base de datos	Existente no testeada
Posibilidad de configurar tareas SITMUN de consulta a servicios web	Existente no testeada

API configuración y autorización

No se prevén modificaciones dea este componente durante el desarrollo de esta funcionalidad.

API de proxy

No se prevén modificaciones dea este componente durante el desarrollo de esta funcionalidad.

Esquema de base de datos

No se prevén modificaciones dea este componente durante el desarrollo de esta funcionalidad.

Mejora UI del login y dashboard de usuario del cliente SITMUN 3

Aspectos generales

Estimación horas de desarrollo: 40 horas

Entidad solicitante: Comisión técnica SITMUN

Prioridad: ALTA

Persona o entidad de referéncia o contacto: Consell Insular de Menorca

Objetivo

Este proyecto busca mejorar el diseño y la funcionalidad de la interficie de acceso y selección de los clientes SITMUN disponibles para un usuario concreto, dotándolas de un diseño más amigable, claro y funcional. Se busca además ampliar la funcionalidad actual.

Contexto y casos de uso

En las imágenes siguientes se puede ver la actual ventana de login y selección de aplicación del actual cliente SITMUN 3.

En la imagen siguiente se puede ver el dashboard inicial:

Se hace necesario mejorar el diseño de ambas ventanas y ampliar la funcionalidad que se ofrece al usuario.

Requerimientos funcionales

Se prevé la siguiente lógica funcional:

1. Acceso a SITMUN. Desde la ventana de login se permite entrar en el espacio de usuario, que ofrece acceso a las distintas combinaciones de aplicación y territorio sobre las que un usuario tiene permisos. Así mismo, y de forma diferenciada en la interficie de usuario, se ofrece acceso a las aplicaciones públicas. La ventana de acceso incorpora, además del espacio de usuario/password una opción de acceso 'público' permite el acceso a un espacio público que únicamente ofrece el listado de aplicaciones / territorio que son de carácter público.

2. Una vez logeado al espacio de usuario se ofrecerá al usuario de forma clara el listado de territorios y de aplicaciones. El listado de territorios se ofrece como una lista de todos los territorios a los que el usuario tiene acceso con una opción 'todos' por defecto que no realiza filtro sobre las aplicaciones. En caso de que un usuario tenga acceso a muchos territorios y este hecho dificulte presentar las opciones sin filtrar por volumen, aparecerá un aviso a la pantalla principal pidiendo al usuario que seleccione un territorio de la lista. El listado de aplicaciones se presenta como un conjunto de elementos con características (imagen, descripción, territorio i último acceso). La ventana de usuario ofrece la siguiente funcionalidad:

   • Opción de consultar los datos de usuario en el SITMUN (territorio, rol, caducidad…) y gestionar determinados datos de usuario (cambiar el correo electrónico, el teléfono y la contraseña)
   • Informar de forma clara de: fecha del último acceso a SITMUN, fecha de último acceso para cada aplicación, fecha de caducidad de los permisos para cada aplicación/territorio,
   • Espacio de notícias y comunicados para que el administrador SITMUN pueda enviar mensajes a cada usuario en función de sus permisos de acceso.
   • Acceso diferenciado a las aplicaciones públicas.
   • Buscador de territorios
   • Cambio de idioma
   • Logout

A continuación se presenta de forma ilustrativa el concepto de interficie. Este diseño es solo demostrativo para plasmar la idea inicial de la Red SITMUN, la empresa contractante deberá desarrollar esta idea y plantear una o varias propuestas de GUI. En la propuesta de diseño se pondrá énfasis en crear una imagen moderna, clara y funcional para el usuario y que sea responsiva.

Se identifican los siguientes requerimientos funcionales a desarrollar para cada uno de los componentes de la arquitectura de SITMUN.

Cliente Administrador

Funcionalidad	Estado	Issues relacionadas
Añadir noticias, avisos o mensajes para todos los usuarios, para un rol o un usuario concreto. Cada noticia ha de tener, por lo menos, un título, texto (multiidioma), una imagen y la posibilidad de agregar enlaces.	Nueva
Asociar una imagen o thumbnail a cada aplicación	Existente no testeada

Cliente visualizador (Dashboard de usuario)

Funcionalidad	Estado	Issues relacionadas
Mejorar el diseño de la ventana de login, más claro y responsive	Nueva
Mejorar el diseño de la ventana del dashboard de usuario	Nueva
Ofrecer la opción de cambio de contraseña desde la ventana de login	Nueva
Presentar territorios disponibles en forma de lista, con un buscador que realice filtro dinámico. Si no hay territorios seleccionados se tienen que presentar todas las aplicaciones. Al seleccionar un territorio de la lista se presentan las aplicaciones disponibles para ese territorio	Nueva
Añadir espacio para consultar datos de usuario: nombre usuario, fecha última conexión, número de conexiones y tiempo de conexión total del último mes, tabla de datos asociados al territorio, con la opción de, por lo menos, poder modificar la contraseña	Nueva
Crear un espacio en el dashboard para crear noticias y mensajes / avisos del administrador hacia los usuarios	Nueva
Diferenciar estilos de ventanas login, dashboard y cliente visualizador y simplificar al máximo el diseño de la barra para el cliente para interferir al mínimo en el diseño del visor (p.e. barra transparente y boton pequeño en margen superior derecho).	Nueva

API de autenticación

No se prevén modificaciones dea este componente durante el desarrollo de esta funcionalidad.

API de administración

Funcionalidad	Estado	Issues relacionadas
Incorporar los parámetros necesarios para configurar el listado de aplicaciones (descripción, imagen, título, fecha de caducidad, fecha último acceso) accesibles para el usuario en la aplicación de Administdración SITMUN 3	Nueva
Incorporar los parámetros necesarios para configurar en el dashboard las comunicaciones y notícias (título, descripcion, enlaces, imagen) para cada usuario desde la aplicación de administración SITMUN 3	Nueva

API configuración y autorización

No se prevén modificaciones de este componente durante el desarrollo de esta funcionalidad.

API de proxy

No se prevén modificaciones dea este componente durante el desarrollo de esta funcionalidad.

Esquema de base de datos

Funcionalidad	Estado	Issues relacionadas
Analizar e incorporar a la bbdd, si se requiere, los campos necesarios para permitir almacenar los parámetros necesarios para configurar el listado de aplicaciones	Nueva
Analizar e incorporar a la bbdd si se requiere, los campos necesarios para configurar en el dashboard las comunicaciones y noticias para cada usuario	Nueva

Cliente APP SITMUN aplicada a los recursos turísticos

Aspectos generales

Estimación horas de desarrollo: 2.500 horas

Entidad solicitante: Consell Insular de Menorca

Prioridad: MEDIA

Persona o entidad de referència o contacto: Consell Insular de Menorca

Objetivo

Esta funcionalidad busca dotar a la plataforma SITMUN de la capacidad de configurar aplicaciones móviles a través de un primer caso de uso de una APP turística.

Contexto y casos de uso

Hasta este momento desde el administrador SITMUN se pueden configurar clientes web, gestionando los contenidos, las funcionalidades y los permisos de acceso a los mismos. El objetivo con esta nueva funcionalidad es ampliar el tipo de clientes SITMUN y que, desde el administrador SITMUN se pueda configurar un nuevo tipo de clientes: aplicaciones para dispositivos móviles.

La idea principal es aprovechar la potencia y versatilidad de SITMUN, como plataforma de administración de aplicaciones, para poder gestionar los contenidos (y funcionalidades) de aplicaciones para dispositivos móviles.

El siguiente ejemplo ilustra la idea de funcionalidad que se requiere.

En la imagen de la izquierda se puede ver el menú principal de una APP, mientras en la imagen de la derecha se representa cómo se podría configurar este menú en el administrador SITMUN.

Requerimientos funcionales

Al objeto del presente documento, se entenderá por aplicación cliente como la aplicación final para dispositivos móviles (tanto Android como iOS) que debe estar disponible en las plataformas correspondientes y que ofrecerá información (turística) y funcionalidades asociadas al usuario.

Por administrador (de aplicaciones) SITMUN se entenderá la aplicación web de la plataforma SITMUN que permite la configuración de aplicaciones por usuario final. Esta aplicación ya está desarrollada en una versión beta inicial.

El administrador SITMUN ha de disponer de la capacidad de poder configurar los apartados, contenido y funcionalidades de una APP de forma flexible.

En el ejemplo anterior (en el contexto) se ilustra la configuración del menú principal. El siguiente ejemplo ilustra la configuración del contenido un apartado específico.

Por último, se ilustra cómo se podría definir el contenido de uno de los subapartados de la imagen anterior. De forma que dicho contenido no se define en el administrador SITMUN sino que se define los parámetros de conexión al servicio web o base de datos que contiene los datos que se van a representar.

A partir de la lógica que se define a través de estos ejemplos de aplicación, los requerimientos funcionales generales de la APP cliente SITMUN son:

• Presentar la secuencia o flujo de aplicación de acuerdo con aquello definido en administrador SITMUN. Cada punto o entrada del menú con sus atributos (imagen, título, descripción…) y anidada correctamente según la estructura definida.
• Presentar los datos obtenidos a través de una conexión a base de datos o servicio web definido en el administrador SITMUN.
• Disponer de un mapa que permita visualizar todos los contenidos georeferenciados del mismo árbol de contenidos de la aplicación.
• Marcar los lugares de interés favoritos.
• Proponer al resto de usuarios otros lugares de interés.

Para el administrador SITMUN los requerimientos funcionales son:

• Definir el menú y submenú de la aplicación a partir de la definición de nodos y subnodos de árbol del administrador SITMUN.
• Configurar los contenidos del cliente APP a partir de la configuración de conexiones a servicios de mapas, servicios web, API y/o conexiones a bases de datos.
• Configurar las funcionalidades de la APP a partir de la configuración de tareas SITMUN.

Se identifican los siguientes requerimientos funcionales a desarrollar para cada uno de los componentes de la arquitectura de SITMUN:

Cliente Administrador

Funcionalidad	Estado	Issues relacionadas
Permitir que un árbol pueda incorporar no solo capas sino también tareas SITMUN.	Nueva
Ampliar los atributos para cada nodo del árbol de aplicación	Nueva

Cliente visualizador (API SITNA)

No se prevén modificaciones dea este componente durante el desarrollo de esta funcionalidad.

API de autenticación

No se prevén modificaciones dea este componente durante el desarrollo de esta funcionalidad.

API de administración

No se prevén modificaciones dea este componente durante el desarrollo de esta funcionalidad.

API configuración y autorización

No se prevén modificaciones dea este componente durante el desarrollo de esta funcionalidad.

API de proxy

No se prevén modificaciones dea este componente durante el desarrollo de esta funcionalidad.

Esquema de base de datos

No se prevén modificaciones dea este componente durante el desarrollo de esta funcionalidad.

Informe

Aspectos generales

Estimación horas de desarrollo: ?? horas

Entidad solicitante: Agueda Isern, Consell Insular de Mallorca

Prioridad: BAJA

Persona o entidad de referéncia o contacto: Agueda Isern, Consell Insular de Mallorca

Objetivo

Esta funcionalidad busca dotar a SITMUN 3 de la capacidad de configurar, desde el administrador SITMUN 3, el contenido de una ventana que devuelve el visor SITMUN 3 cuando el usuario busca una referencia catastral o dirección del visor o como información complementaria del "Más info".

El contenido de la ventana debe poder integrar el mapa de una parcela, la respuesta de varias consultas definidas como tareas al propio administrador y otros textos e imágenes que pueden ser fijos para cada territorio.

Contexto y casos de uso

Como ejemplo se puede observar el funcionamiento de SITMUN 2 en el caso de los visores de urbanismo del Consell de Mallorca, en el geoportal IDELMA. Actualmente, los informes pueden generarse a partir de un localizador o dentro de información avanzada de una consulta. En la ventana siguiente podemos observar el detalle de la ventana con distintas pestañas, cada una de ellas se corresponde con el resultado de una tarea de tipo consulta configurada en el administrador SITMUN 2.

Actual ventana de ejemplo de configuración de una tarea tipo consulta en SITMUN 2.

El informe en el SITMUN 2 que funciona a partir de un localizador se genera a partir de una plantilla fija, un mapa (a través de un grupo de capas) y una serie de consultas:

Actual ventana de ejemplo de configuración de una tarea tipo informe en el SITMUN 2. Para generar el informe en el cliente se introduce una referencia catastral, se selecciona el objeto encontrado y el cliente descarga un archivo en formato PDF:

Ejemplo de informe del SITMUN 2.

Requerimientos funcionales

Se prevé la siguiente lógica funcional:

1. Configurar la apariencia de la ventana tipo layout que generará el informe: logos, títulos, textos explicativos y cualquier aspecto del estilo de la plantilla (color, letra, ubicación de los diferentes objetos de la plantilla). Cada uno de ellos son objetos que el administrador permite colocar y darle un tamaño determinado dentro de la plantilla.
2. Configurar el localizador. Para que se genere el informe, primero el usuario busca una referencia catastral o dirección.
3. Configurar el “Más info” en el caso de querer generar el informe como información de un objeto.
4. Configurar el mapa. En el SITMUN 3 el mapa se configura seleccionando las capas que deben aparecer y su orden, así como la escala del mapa.
5. Configurar consultas. En el administrador SITMUN 3 se definen distintos tipos consultas a bases de datos, consultas a servicios… que formaran parte de la ventana del informe.

Por ejemplo, en el caso del visor urbanístico anterior, se establecen varias consultas:

• Una primera tarea que consiste en consulta que devuelve toda la información relativa a la cualificación de la parcela: casco antiguo, residencial extensiva, residencial intensiva, etc.
• Una segunda consulta que devuelve la información relativa al Patrimonio arquitectónico
• Una tercera consulta que devuelve la referencia catastral y dirección de la parcela seleccionada

• Una imagen de la fachada del edificio o una imagen de una tabla de un texto

• Una vez definidas estas tareas, que llamaremos tareas hijas, se configuraran en el administrador SITMUN la tarea padre informe. En la ventana de configuración de dicha tarea se podrá:

  • Configurar la plantilla del informe
  • Establecer el mapa, así como la escala, que aparecerá en el informe
  • Establecer las consultas que deben aparecer en el informe
  • Establecer las imágenes que aparecerán en el informe
  • Definir qué territorios y roles de usuario tienen asociada esta funcionalidad.
• Cliente SITMUN - API SITNA deberá configurar correctamente la ventana de informe cuando se realice la búsqueda de la referencia catastral o la dirección o cuando se active el “Más info”.

Se identifican los siguientes requerimientos funcionales a desarrollar para cada uno de los componentes de la arquitectura de SITMUN:

Cliente Administrador

Funcionalidad	Estado	Issues relacionadas

Cliente visualizador (API SITNA)

Funcionalidad	Estado	Issues relacionadas

API de autenticación

No se prevén modificaciones dea este componente durante el desarrollo de esta funcionalidad.

API de administración

No se prevén modificaciones dea este componente durante el desarrollo de esta funcionalidad.

API configuración y autorización

No se prevén modificaciones dea este componente durante el desarrollo de esta funcionalidad.

API de proxy

No se prevén modificaciones dea este componente durante el desarrollo de esta funcionalidad.

Esquema de base de datos

No se prevén modificaciones dea este componente durante el desarrollo de esta funcionalidad.

Ended: Propuestas

Ended: Características

Referencia

Arquitectura de SITMUN 3

SITMUN 3 es un sistema de código libre para poner en marcha sistemas de información territoriales donde múltiples usuarios puedan acceder a distintas aplicaciones según sus necesidades. Esto incluye:

• Aplicaciones web de usuario final. La aplicación “básica” es un visor de mapas web, pero hay otras y pueden tomar formas muy distintas si es necesario. En general, estas aplicaciones deben ser configuradas para resultar útiles. Esta configuración incluye indicar las herramientas específicas que van a ofrecer a sus usuarios, así como los servicios, capas o bases de datos accesibles; también incluye restricciones de acceso, basadas en usuarios, roles y territorios concretos. P. ej., una aplicación puede ser el visor de mapas básico. Y si te identificas como usuario “público” del territorio “Municipio X” esa configuración describe cómo en el árbol de capas del mapa tienen que aparecer ciertos servicios web de mapas, y no otros, y no debe aparecer ninguna herramienta que permita modificar datos o acceder a BD privadas. Estas aplicaciones obtienen su configuración cada vez que arrancan (porque depende del usuario, rol y territorio que se haya identificado, y porque puede haber cambiado desde la vez anterior) de una API REST. Esta API accede a la BD de SITMUN y no es la misma que usa la aplicación web de administración. Y finalmente aplican la configuración obtenida antes de permitir a los usuarios ponerse a trabajar.
• Aplicación web de administración. Esta aplicación es para que los administradores de las organizaciones que instalan SITMUN 3 configuren las aplicaciones que quieran ofrecer a sus usuarios. P. ej., podemos añadir un nuevo servicio de mapas públicamente accesible que acabamos de encontrar al visor de mapas básico para usuarios públicos de cualquier territorio. La próxima vez que un usuario público acceda verá que hay una capa más que la vez anterior. Esta aplicación lee y modifica los datos en la BD de SITMUN 3 a través de una API REST.
• Componentes adicionales. Se usan en varias aplicaciones, (tanto en la de administración como en las de usuario final):
  • Proxy: es un proxy inverso para que se pueda dar acceso a servicios y bases de datos protegidos (bien sea porque están en una Intranet, y los usuarios están fuera de ella, o bien porque requieren credenciales de acceso y los usuarios no las deben conocer, o bien porque quiere modificarse la información que ofrecen antes de devolverla a la aplicación cliente, por ejemplo, enmascarando parte de una imagen con un mapa). Es un proxy inverso y, por tanto, el cliente no puede elegir usarlo o no, y esencialmente le resulta transparente.
  • API de autenticación: permite a los usuarios y administradores identificarse utilizando distintos mecanismos que puedan estar disponibles en las distintas organizaciones (Microsoft Active Directory, servicios LDAP y otros).

SITMUN 3 no tiene un conjunto de datos o servicios geográficos/territoriales predefinidos. Cada despliegue de SITMUN 3 se hace para una organización concreta, normalmente supramunicipal, y esta organización debe decidir qué aplicaciones quiere ofrecer a sus usuarios, típicamente personal técnico de los municipios, y qué servicios y datos geográficos/territoriales van a estar accesibles en estas aplicaciones. Estos servicios y bases de datos los tendrá que tener en sus propios sistemas, o bien tendrán que estar en algún sitio al que puedan acceder.

Las aplicaciones de usuario final de SITMUN 3 interactúan relativamente poco con las API y componentes de SITMUN 3:

• Con la API de autenticación solo al principio, para identificar al usuario.
• Con la API de configuración solo en el arranque.
• La mayor parte de las peticiones las van a hacer contra servicios de mapas y bases de datos.
• Las que sean intranet, protegidas etc. irán a través del proxy, las demás serán directas.

Esto conviene tenerlo en cuenta cuando estemos dimensionando el hardware que necesitamos para el despliegue, y cómo lo vamos a repartir.

SITMUN 3 tiene una arquitectura de 3-tiers. Las aplicaciones web se desarrollan con Angular 16, Spring Boot 3 se usa en el tier web, y una base de datos relacional (PostgreSQL 16, Oracle 23c, o H2 para desarrollo a día de hoy, pero se pueden usar otras) en el tier de datos.

Principales componentes

Escenario típico de uso

Un escenario típico de uso que ejemplifica la interacción de estos componentes sería:

1. El usuario abre una aplicación de SITMUN, por ejemplo, un visor de información territorial, selecciona un territorio y se autentica. Para ello, el visor interactúa con el Servicio de Autenticación, obteniendo un token JWT.
2. El visor obtiene la información para su configuración para este usuario, territorio y aplicación interactuando directamente con el Servicio de Configuración y Autorización. A esta petición el visor le ha añadido el token JWT, el identificador de territorio y el identificador de aplicación.
3. El usuario interactúa con el visor y, por ejemplo, hace visible una capa que corresponde a un servicio WMS restringido por territorio o realiza una búsqueda entre los datos alfanuméricos del padrón municipal de habitantes de un municipio. Esta petición ocurrirá a través del Servicio de proxy. A esta petición el visor le ha añadido el token JWT, el identificador de territorio y el identificador de aplicación.
4. Con esta información, el Servicio de proxy interactúa con el Servicio de Configuración y Autorización para determinar si puede hacer la petición y, si puede hacerla, cómo debe interrogar este servicio restringido. En este caso, por ejemplo, qué parámetros adicionales hay que añadir a la petición para limitar la respuesta a un territorio concreto.
5. Después, el Servicio de proxy hace la petición al servicio WMS restringido con estos parámetros adicionales y devuelve la respuesta al visor tras aplicar alguna transformación si fuera necesaria.

Diagramas de secuencia

En esta sección se documentan algunas de las interacciones más relevantes del sistema en forma de diagramas de secuencia.

Login

Uso del proxy para acceder a un WMS privado

Uso del proxy para acceder a una BD en Intranet

Diagrama de módulos

sitmun-backend-core es un proyecto multi módulo.

Hay 3 tipos de módulos:

• Módulos estables (en amarillo). Lógica principal de SITMUN 3 y componentes de soporte.
• Módulos de desarrollo (en naranja). Datos de prueba, despliegues de prueba y herramientas de apoyo (front end y línea de comandos).
• Módulos legados (en gris). Clases y funcionalidades que se han ido desechando y que todavía no han sido eliminadas definitivamente.

Diagrama de paquetes

Es la biblioteca que contiene la definición del modelo de datos de SITMUN 3, la API de autenticación, la API de configuración y autorización y la política de seguridad.

Paquetes (Arquitectura por Capas)

En general, cada API que en despliegue quede expuesta de manera separada, es decir, con su propio endpoint HTTP, tiene un paquete.

• Paquete authentication que corresponde con la API de Autenticación.
• Paquete authorization que corresponde con la API de Configuración y Autorización.
• Paquete administration que corresponde con la API de Administración.

Cada uno de estos paquetes puede contener:

• Paquete controller: contiene los controladores (clases anotadas con @Controller) y otras cosas necesarias para implementar ese endpoint HTTP.
• Paquete service: contiene los servicios de aplicación específicos del API (clases anotadas con @Service) y clases asociadas. Estos servicios solo se invocarán desde los controladores del paquete controller.
• Paquete config: contiene la configuración específica de los componentes del endpoint definidos en los paquetes web y service. Normalmente, son clases anotadas con @Configuration y parte de la configuración puede estar referida a clases de infraestructura (de biblioteca) de Spring Framework.

Además, hay dos paquetes adicionales:

• Paquete domain que contiene las clases y los tipos del modelo de SITMUN 3. Es decir, el modelo que permite definir aplicaciones SITMUN 3, los territorios en los que están disponibles, a qué servicios territorios y bases de datos pueden acceder y qué usuarios pueden utilizarlas. Los paquetes que contienen las clases de dominio están anidados, de tal forma que las clases de dominio dependientes de otra aparecen en un paquete anidado en el paquete que contiene la clase principal. Las entidades del paquete entities se exponen a través de la API de Administración usando el framework Spring Data REST.
• Paquete infrastructure que describe los componentes de infraestructura (persistencia, seguridad, web).

El paquete infrastructure contiene:

• Paquete persistence. Se divide en tres paquetes: el paquete definition con constantes, el paquete entities con las clases de dominio, y el paquete types con los tipos del dominio. El paquete entities, además de las clases de dominio, contiene agrupadas junto a la clase formando paquetes la definición de los accesos a base de datos (interfaces anotadas con @Repository), las definiciones de las proyecciones y mecanismos de validación de datos del dominio. El paquete types contiene la definición de conversores y anotaciones que permiten ser más expresivo en la definición del modelo en el paquete entities.
• Paquete security que contiene la configuración del framework de seguridad Spring Security. Spring Security proporciona diversas formas de aplicar seguridad a nivel de la aplicación que permite establecer políticas de acceso a controladores, servicios y repositorios en función del rol que se le asigne al usuario en función de sus credenciales: USER, ADMIN, PROXY. Además, este paquete asegura que todos los accesos anónimos sean identificados como un acceso con usuario público.

La relación de las API públicas con el paquete securityes la siguiente:

• La API de Autenticación del paquete authentication usa servicios y componentes de Spring Framework configurados por el paquete security para autenticar un usuario cuando solicita un token JWT de autenticación.
• Los controladores de la API de Configuración y Autorización solo podrán ser accedidos por usuarios a los se haya determinado que tengan el rol USER (clientes SITMUN 3) o el rol PROXY (proxy). Es misión del paquete security establecer los filtros necesarios para interceptar las peticiones y en función de los mecanismos de seguridad implementados (token JWT para el rol USER, API key para el rol PROXY) determinar si están autenticadas y asignar la identidad y el rol correspondiente.
• Los controladores de la API de Administración (tanto los definidos explícitamente como los generados dinámicamente por Spring Data REST) solo podrán ser accedidos por usuarios a los que se haya determinado que tengan el rol ADMIN. Como en el caso anterior, es misión del paquete security establecer los filtros necesarios para interceptar las peticiones y en función de los mecanismos de seguridad implementados (token JWT para el rol ADMIN) determinar si están autenticadas y asignar la identidad y el rol correspondiente.

Como se puede deducir de las explicaciones anteriores:

• La API de Autenticación expone vía una API Web mecanismos para interactuar con el sistema de seguridad de la aplicación definido en security.
• La API de Administración expone vía una API Web mecanismos para modificar el estado de los objetos de dominio definidos en domain por parte de los administradores.
• La API de Configuración y Autorización expone vía una API Web mecanismos para obtener una configuración derivada del estado actual de los objetos de dominio definidos en domain en función de la identidad y rol del que solicita la información.

Clases

Diseño

Servicio de Autenticación

El Servicio de Autenticación permite que los usuarios se identifiquen en la plataforma SITMUN. Tras la identificación, este servicio devuelve un token de acceso JSON web token (JWT) que permite al usuario acceder a los servicios de la plataforma. SITMUN almacena las contraseñas de los usuarios en la base de datos SITMUN usando un hash criptográfico (bcrypt). También está soportada la autenticación a través de un servidor LDAP. Hay que señalar que está planteado soportar la autenticación de usuarios a través de Active Directory (AD) y de certificados digitales.

Este servicio se expone vía la API de Autenticación.

Comportamiento esperado

El Servicio de Autenticación puede funcionar de dos formas distintas tras recibir la petición de un usuario.

El comportamiento espera es el siguiente:

1. Si no se configura el uso de un LDAP externo, el Servicio de Autenticación comprueba si el usuario y la contraseña son válidos en SITMUN y pasa al punto ④.
2. Si se configura el uso de un LDAP externo, el Servicio de Autenticación comprueba si el usuario y la contraseña son válidos en el LDAP externo.
3. Si el usuario es válido, el Servicio de Autenticación comprueba si el usuario es válido en SITMUN.
4. Si el usuario es válido en SITMUN, el Servicio de Autenticación genera un token de acceso que es devuelto al cliente.

Servicio de Configuración y Autorización

El Servicio de Configuración y Autorización se encarga de determinar qué puede hacer el Servicio de Proxy en cada petición realizada por un usuario. Si la petición no contiene el token de acceso del usuario, se asumirá que es una petición realizada para el usuario público.

Este servicio se expone vía la API de Configuración y Autorización.

Servicio de Proxy

Un componente clave del sistema es un proxy inverso que actúa como un intermediario entre los clientes de SITMUN y diversas fuentes de datos, como servicios web y bases de datos remotas, permitiendo controlar el acceso a la información, ya sea geográfica o no.

El proxy inverso es capaz de manejar peticiones a diversos tipos de servicios, incluyendo:

• Servicios OGC Web Map Service (WMS), que ofrecen mapas en formato imagen usando peticiones HTTP GET.
• Servicios OGC Web Map Tile Service (WMTS), que proporcionan mapas divididos en teselas (tiles) usando peticiones HTTP GET (codificación KVP).
• Servicios OGC Web Feature Service (WFS), que permiten el acceso a datos geoespaciales vectoriales usando peticiones HTTP GET (codificación KVP).
• Bases de datos relacionales que dispongan de un controlador (driver) JDBC (Java Database Connectivity). Las respuestas de las bases de datos se devuelven en formato JSON usando peticiones HTTP GET.

Para acceder a través del proxy, todas las peticiones deben incluir un token de acceso JWT, obtenido previamente a través de la API de autenticación, la cual identifica al usuario. La única excepción es el usuario denominado público, cuya autenticación es automática. Es decir, en caso de no incluir un token de acceso JWT, se asume que se trata del usuario público. Además, todas las peticiones enviadas a través del proxy deben incluir un identificador de territorio y un identificador de aplicación.

El proxy actúa como adaptador, traduciendo las peticiones de los clientes SITMUN a un formato adecuado para los servicios y datos subyacentes. Para realizar esta tarea, el proxy utiliza la API de configuración y autorización, que proporciona al proxy la información necesaria para construir las solicitudes a los servicios y adaptar las respuestas recibidas.

Ejemplos de uso del proxy son los siguientes:

• El proxy permite a los clientes interactuar con servicios restringidos sin que el usuario tenga que conocer las credenciales o la URI de los mismos.
• El proxy puede filtrar la información proporcionada por un OGC WMS, ocultando la parte que no corresponde al territorio indicado en la petición.

Este servicio se expone a través de la API de Proxy, que actúa como punto de entrada para las solicitudes relacionadas.

Comportamiento esperado

A continuación se muestra el comportamiento esperado del proxy.

El comportamiento esperado es el siguiente:

1. El visor de mapas hace una petición que es servida por el proxy.
2. El proxy realiza una petición a la API de configuración y autorización en el backend para obtener la configuración.
3. La API de configuración y autorización proporciona la configuración de la petición al servicio remoto al proxy.
4. El proxy compone una petición adecuada al servicio remoto y la envía.
5. El servicio remoto devuelve una respuesta.
6. Si es necesario, el proxy aplica una transformación a la respuesta.
7. El proxy devuelve la respuesta al visor de mapas.

Ejemplo: OGC WMS

Las peticiones a la API de Proxy tienen la siguiente forma:

GET /proxy/{appId}/{terId}/{type}/{typeId}?{keys*}
Authorization: Bearer {JWT token}

Lo que permite identificar:

• appId: identificador de la aplicación que realiza la petición.
• terId: identificador del territorio en el que se realiza la petición.
• type: tipo de servicio que se solicita.
• typeId: identificador del servicio que se solicita.
• keys: parámetros adicionales que se envían al servicio.
• token: token de autenticación JWT.

Por ejemplo, la siguiente petición correspondería con la petición de acceso a un servicio de mapas remoto:

GET /proxy/1/34/wms/1?SERVICE=WMS&REQUEST=GetMap
    &LAYERS=SITMUN
    &FORMAT=image/png
    &TRANSPARENT=true&VERSION=1.1.1&SRS=EPSG:25831
    &BBOX=405913.25142303,4593667.2516974,411183.74857697,4599953.7483026
    &WIDTH=498&HEIGHT=594
Authorization: Bearer SOME-TOKEN    

La petición que el proxy realizaría al endpoint /api/config/proxy de la API de configuración y autorización sería:

{
  "appId": 1,
  "terId": 34,
  "type": "WMS",
  "typeId": 1,
  "method": "GET",
  "parameters": {
    "SERVICE": "WMS",
    "REQUEST": "GetMap",
    "LAYERS": "SITMUN",
    "FORMAT": "image/png",
    "TRANSPARENT": "true",
    "VERSION": "1.1.1",
    "SRS": "EPSG:25831",
    "BBOX": "405913.2514230,4593667.251697,411183.7485769,4599953.748302",
    "WIDTH": "498",
    "HEIGHT": "594"
  },
  "id_token": "SOME-TOKEN"
}

La respuesta podría ser como sigue:

{
  "type": "OgcWmsPayload",
  "exp": 1623340800,
  "payload": {
    "vary": [
      "BBOX"
    ],
    "uri": "https://geoserveis.icgc.cat/icgc_bm5m/wms/service",
    "method": "GET",
    "parameters": {
      "SERVICE": "WMS",
      "REQUEST": "GetMap",
      "LAYERS": "01_NIVJERARQUIC_LN,02_TIPUSLINIA_LN",
      "FORMAT": "image/png",
      "TRANSPARENT": "true",
      "VERSION": "1.1.1",
      "SRS": "EPSG:25831",
      "BBOX": "405913.2514230,4593667.251697,411183.7485769,4599953.748302",
      "WIDTH": "498",
      "HEIGHT": "594"
    }
  }
}

La petición a realizar por el proxy debe:

• Ser a la URI indicada en el campo uri de la respuesta.
• Con el método HTTP indicado en el campo method de la respuesta.
• Con los campos y valores indicados en el campo parameters de la respuesta.
• Con los campos y valores indicados en el campo vary de la petición del visor de mapas.

Es decir:

GET /icgc_bm5m/wms/service?SERVICE=WMS&REQUEST=GetMap
    &LAYERS=01_NIVJERARQUIC_LN,02_TIPUSLINIA_LN
    &FORMAT=image/png
    &TRANSPARENT=true&VERSION=1.1.1&SRS=EPSG:25831
    &BBOX=405913.25142303,4593667.2516974,411183.74857697,4599953.7483026
    &WIDTH=498&HEIGHT=594
Host: geoserveis.icgc.cat

Referencia

API de Autenticación

La API de Autenticación expone vía una API Web mecanismos para interactuar con el sistema de seguridad de SITMUN. Esta API se ha creado para que la aplicación de administración y los visores de mapas obtengan, tras pasar las credenciales de usuario obtengan un token de acceso JSON web token (JWT) necesario para operar con el resto de las API.

API de Configuración y Autorización

La API de Configuración y Autorización expone vía una API Web mecanismos para obtener una configuración derivada del estado actual de los objetos de dominio en función de la identidad y rol del que solicita la información. Esta API se ha creado para que los visores de mapas y el proxy puedan configurarse.

La API de Configuración y Autorización se compone de dos tipos de endpoints:

• Configuración y Autorización de Visor de mapas. La petición pueden autenticarse usando un esquema de autenticación por portador (Bearer authentication) usando un token que se ha obtenido previamente mediante la API de Autenticación. Si no se autentica, se asume que la petición se ha realizado por un usuario que en el dominio de SITMUN 3 se denomina usuario público.
• Configuración y Autorización de Proxy. La petición debe autenticarse usando una API key enviada mediante la cabecera denominada X-SITMUN-Proxy-Key. El uso de una API key específica para el endpoint Configuración y Autorización de Proxy es una decisión de seguridad. Evita que a un cliente malicioso le pueda bastar el uso del token obtenido de la API de Autenticación para obtener secretos vía el endpoint Configuración y Autorización de Proxy.

API de Proxy

La API de Proxy (Proxy Middleware) permite acceder a los visores de mapas a servicios remotos y bases de datos.

Los visores de mapas pueden autenticarse usando un esquema de autenticación por portador (Bearer authentication) usando un token que se ha obtenido previamente mediante la API de Autenticación. Si no se autentica, se asume que la petición se ha realizado por un usuario que en el dominio de SITMUN 3 se denomina usuario público.

API de Administración

La API de Administración expone vía una API Web mecanismos para modificar el estado de los objetos de dominio de SITMUN 3 por parte de la aplicación de administración. La aplicación de administración debe autenticarse con un JSON Web Token obtenido de la API de Autenticación.

Configuración

En desarrollo

Esta sección está siendo actualizada.

Backend

API de Autenticación

Estas propiedades se utilizan para configurar el acceso al servidor LDAP para autenticar a los usuarios.

Condición de activación

Estas propiedades se utilizan solo si está activado el perfil ldap. Deben almacenarse en un fichero separado denominado application-ldap.yml.

Propiedad	Descripción	Valor por defecto
sitmun.authentication.ldap.url	Localización del servidor LDAP
sitmun.authentication.ldap.base-dn	Contexto raíz para todas las operaciones LDAP
sitmun.authentication.ldap.user-dn-pattern	Patrón que identifica el usuario
sitmun.authentication.ldap.password	La contraseña a utilizar cuando se autentique con el servidor LDAP	nulo

API de Configuración y Autorización

Propiedad	Descripción	Valor por defecto
sitmun.proxy-middleware.config-response-validity-in-seconds	Duración máxima (en segundos) de validez de la respuesta de configuración	3600
sitmun.proxy-middleware.secret	Secreto que usa el componente proxy para autenticarse

Mediante las siguientes propiedades se puede forzar la reescritura de las URI de los servicios en las repuestas de configuración para clientes de mapas para que apunten al componente Proxy.

Propiedad	Descripción	Valor por defecto
sitmun.proxy-middleware.force	Fuerza el uso del proxy de SITMUN	false
sitmun.proxy-middleware.url	Localización del proxy de SITMUN

Proxy

Propiedad	Descripción	Valor por defecto
sitmun.backend.config.url	Ruta al endpoint de configuración del proxy en la API de configuración y autorización
sitmun.backend.config.secret	Secreto que usa el proxy para autenticarse (ver API de configuración y autorización)

Visor de mapas

Propiedad	Descripción	Valor por defecto
apiUrl	La URL pública donde se despliega el backend.	http://localhost:9000/backend

Administrador

Propiedad	Descripción	Valor por defecto
apiBaseURL	La URL pública donde se despliega el backend.	http://localhost:9000/backend

Gestión

En líneas generales se trata de mantener una gestión ágil, dentro de las limitaciones impuestas por un proyecto de estas características, coordinado entre varias administraciones públicas que a su vez subcontratan la mayor parte de los esfuerzos de desarrollo a distintos adjudicatarios. El equipo de coordinación técnica del proyecto es el punto de contacto ante cualquier duda que surja sobre estas cosas.

Trabajo en GitHub

Se trabaja en abierto sobre GitHub, bajo el paraguas de la organización SITMUN.

• Los desarrolladores y desarrolladoras tienen que crear cuentas en GitHub y se les darán los permisos necesarios para trabajar en repositorios en esa organización.
• La gestión del trabajo (tareas/incidencias) se hace usando GitHub Issues. En ocasiones se usan tableros de proyecto de GitHub, esto depende del subproyecto concreto y se acuerda con los desarrolladores en cada caso. En cualquier caso, los tableros de proyecto solo son una forma distinta de ver las tareas/incidencias de GitHub Issues.
• La construcción y despliegue automáticos se hace usando GitHub Actions.
• En general, se proporciona acceso directo, en lectura y escritura, a los repositorios necesarios. No hay un equipo de desarrollo principal que haga el grueso del trabajo y luego pequeñas contribuciones puntuales de otros, así que el modelo de forks y pull requests no es, por ahora, adecuado.
• El equipo de coordinación técnica del proyecto tiene que tener acceso a los desarrollos en tiempo real para poder cumplir su papel de coordinación y de validación técnica de los resultados.

Automatización de procesos

En general haremos siempre énfasis en la automatización de todo lo que sea automatizable en este proyecto.

• En especial, no se puede trabajar en este proyecto sin tener claro que la automatización de pruebas es una buena práctica inexcusable en el desarrollo de software.
• La construcción y despliegue automáticos, al menos en servidores de pruebas y/o preproducción, también serán el requisito por defecto, salvo muy buena razón en contra. Ahora mismo la construcción y pruebas automáticas se hacen en GitHub Actions. Esto puede evolucionar con el tiempo.
• La construcción automática se hace con Gradle o NPM según sean proyectos Java o Angular. En general, la mejor documentación sobre los procesos de construcción automática son los scripts de GitHub Actions en cada repositorio. En algunos repositorios hay algunos scripts de Bash en /build-scripts. Estos pueden usarse en local, pero de nuevo es importante ver cómo se usan desde los scripts de GitHub Actions, incluyendo qué variables de entorno deben estar configuradas.
• Los secretos (contraseñas o tokens) se gestionan adecuadamente usando GitHub secrets. No hay, ni debe haber, ninguna contraseña o token en ninguna parte de ningún repositorio.
• En algunos repositorios se hace uso de SonarCloud para el análisis estático del código.
• Seguiremos semantic versioning 2.0.0 cuando haya que dar identificadores de versión públicos a algo.

Consideraciones técnicas

El desarrollo de los servicios de backend se hace en Java 17, usando Spring Boot 3.5.4. El desarrollo de las aplicaciones de frontend se hace con TypeScript y Angular 16.2.12. Tanto el Administrador como el Visor de mapas están desarrollados en Angular 16.2.12.

Consideraciones metodológicas

Cualquier desarrollo dentro del marco SITMUN 3 debe cumplir con los siguientes requisitos metodológicos:

• Utilizar una metodología ágil que permita una gestión eficiente del proyecto y una adaptabilidad a los cambios.
• Emplear un conjunto de herramientas que ayuden en las diferentes fases y gestiones del ciclo de desarrollo, facilitando tareas como la planificación, el seguimiento y la colaboración.
• Utilizar git/GitHub para la gestión de versiones, lo que proporciona un control de cambios efectivo y un trabajo colaborativo seguro.
• Aplicar una metodología de pruebas que permita validar automáticamente las funcionalidades desarrolladas, asegurando la estabilidad de la aplicación al introducir nuevas versiones o desarrollos.
• Establecer una metodología para el mantenimiento del sistema, garantizando la correcta gestión de actualizaciones, correcciones de errores y mejoras continuas.
• Realizar una gestión y control eficiente de las funcionalidades incorporadas al sistema, asegurando su correcta implementación y coherencia con los requisitos.
• Realizar auditorías y control de calidad periódicos para asegurar la fiabilidad, seguridad y eficiencia del sistema.
• Utilizar el idioma inglés en el código y los comentarios del mismo, así como en la documentación generada, para facilitar la comprensión y colaboración entre los desarrolladores.

Es importante cumplir con estos requisitos metodológicos para asegurar un desarrollo coherente, eficiente y de alta calidad dentro de SITMUN 3.

Repositorios de GitHub

A continuación se listan los repositorios de la organización SITMUN junto con una breve descripción de cada uno:

• sitmun-viewer-app: Aplicación web para visualizar mapas en la plataforma SITMUN, desarrollada con TypeScript, JavaScript, npm y Angular. Más información.
• sitmun-admin-app: Aplicación de administración para la plataforma SITMUN.
• sitmun-backend-core: Proporciona la lógica de negocio del backend mediante una API REST. Desarrollado en Java 17 y Spring Boot 3. Más información.
• sitmun-proxy-middleware: Proxy a servicios web restringidos y middleware a bases de datos. Desarrollado en Java 17 y Spring Boot 3. Más información.
• sitmun-application-stack: Contiene las configuraciones necesarias para desplegar la plataforma SITMUN utilizando Docker. Más información.
• administration-mobile-app: Aplicación móvil para la administración de SITMUN. Más información.
• touristic-mobile-app: Aplicación móvil turística desarrollada para SITMUN. Más información.

Estos repositorios contienen el código y las configuraciones necesarias para los distintos componentes del sistema SITMUN, abarcando tanto el backend como el frontend y las aplicaciones móviles.

Ended: Referencia

Solución de problemas

Esta sección proporciona soluciones a los problemas más comunes que pueden surgir durante la instalación, configuración y uso de SITMUN 3.

Problemas de instalación

Docker no se inicia

Síntomas: - Error al ejecutar docker compose up - Servicios no se levantan correctamente

Soluciones:

# Verificar que Docker esté ejecutándose
docker --version
docker compose --version

# Limpiar contenedores y volúmenes
docker compose down -v
docker system prune -f

# Reiniciar Docker Desktop (si aplica)
# Reiniciar el servicio Docker en Linux
sudo systemctl restart docker

Puerto ya en uso

Síntomas: - Error: "Port 9000 is already in use" - Servicios no pueden iniciarse

Soluciones:

# Verificar qué proceso usa el puerto
lsof -i :9000  # macOS/Linux
netstat -ano | findstr :9000  # Windows

# Cambiar puerto en docker-compose.yml
# O detener el proceso que usa el puerto

Problemas de memoria

Síntomas: - Contenedores se detienen inesperadamente - Errores de "Out of memory"

Soluciones:

# Aumentar memoria disponible para Docker
# En Docker Desktop: Settings > Resources > Memory

# Verificar uso de memoria
docker stats

# Limpiar recursos no utilizados
docker system prune -a

Problemas de base de datos

Conexión a PostgreSQL falla

Síntomas: - Error: "Connection refused" - Backend no puede conectarse a la base de datos

Soluciones:

# Verificar que PostgreSQL esté ejecutándose
docker ps | grep postgres

# Verificar logs del contenedor
docker logs sitmun-application-stack-postgres-1

# Reiniciar el contenedor de PostgreSQL
docker restart sitmun-application-stack-postgres-1

# Verificar conectividad
docker exec -it sitmun-application-stack-postgres-1 psql -U sitmun3 -d sitmun3

Errores de migración de base de datos

Síntomas: - Error: "Liquibase migration failed" - Tablas no se crean correctamente

Soluciones:

# Limpiar base de datos y volver a migrar
docker exec -it sitmun-application-stack-postgres-1 psql -U sitmun3 -d sitmun3 -c "DROP SCHEMA public CASCADE; CREATE SCHEMA public;"

# Reiniciar el backend para ejecutar migraciones
docker restart sitmun-application-stack-backend-1

Problemas de autenticación

No se puede acceder al administrador

Síntomas: - Error 401 Unauthorized - No se puede hacer login

Soluciones:

# Verificar que el backend esté ejecutándose
curl http://localhost:9001/api/dashboard/health

# Verificar logs del backend
docker logs sitmun-application-stack-backend-1

# Usar credenciales por defecto
# Usuario: admin, Contraseña: admin

Token JWT inválido

Síntomas: - Error: "Invalid JWT token" - Sesión expira inesperadamente

Soluciones:

# Limpiar cookies del navegador
# O usar modo incógnito

# Verificar configuración de JWT en el backend
# Revisar logs para errores de validación

Problemas de frontend

Aplicaciones no cargan

Síntomas: - Página en blanco - Errores 404 en recursos estáticos

Soluciones:

# Verificar que el frontend esté ejecutándose
curl http://localhost:9000

# Verificar logs del frontend
docker logs sitmun-application-stack-front-1

# Verificar configuración de nginx
docker exec -it sitmun-application-stack-front-1 cat /etc/nginx/conf.d/default.conf

Problemas de CORS

Síntomas: - Error: "CORS policy" - Requests bloqueados desde el navegador

Soluciones:

# Verificar configuración CORS en el backend
# Revisar headers en las respuestas HTTP

# Verificar configuración de nginx
# Asegurar que los headers CORS estén configurados

Problemas de red

Servicios no se comunican

Síntomas: - Error: "Connection refused" - Timeouts en requests internos

Soluciones:

# Verificar red de Docker
docker network ls
docker network inspect sitmun-application-stack_default

# Verificar conectividad entre contenedores
docker exec -it sitmun-application-stack-backend-1 ping postgres
docker exec -it sitmun-application-stack-backend-1 ping proxy

Problemas de DNS

Síntomas: - Error: "Name resolution failed" - Servicios no pueden resolverse

Soluciones:

# Verificar resolución DNS dentro de contenedores
docker exec -it sitmun-application-stack-backend-1 nslookup postgres

# Reiniciar red de Docker
docker network prune
docker compose up

Problemas de rendimiento

Aplicación lenta

Síntomas: - Tiempos de respuesta altos - Interfaz no responde

Soluciones:

# Verificar uso de recursos
docker stats

# Aumentar memoria disponible
# Optimizar consultas de base de datos
# Configurar índices apropiados

Problemas de memoria

Síntomas: - Aplicación se cuelga - Errores de "Out of memory"

Soluciones:

# Aumentar heap size de Java
# Configurar variables de entorno:
# JAVA_OPTS="-Xmx2g -Xms1g"

# Monitorear uso de memoria
docker exec -it sitmun-application-stack-backend-1 jstat -gc 1

Logs y debugging

Ver logs de servicios

# Logs de todos los servicios
docker compose logs

# Logs de un servicio específico
docker compose logs backend
docker compose logs postgres
docker compose logs front

# Seguir logs en tiempo real
docker compose logs -f backend

Debugging avanzado

# Acceder a contenedor para debugging
docker exec -it sitmun-application-stack-backend-1 bash

# Verificar configuración de Spring
docker exec -it sitmun-application-stack-backend-1 env | grep SPRING

# Verificar conectividad de base de datos
docker exec -it sitmun-application-stack-backend-1 curl http://localhost:8080/api/dashboard/health

Recuperación de datos

Backup de base de datos

# Crear backup
docker exec -it sitmun-application-stack-postgres-1 pg_dump -U sitmun3 sitmun3 > backup.sql

# Restaurar backup
docker exec -i sitmun-application-stack-postgres-1 psql -U sitmun3 sitmun3 < backup.sql

Restaurar configuración

# Backup de volúmenes
docker run --rm -v sitmun-application-stack_pgdata:/data -v $(pwd):/backup alpine tar czf /backup/pgdata-backup.tar.gz -C /data .

# Restaurar volúmenes
docker run --rm -v sitmun-application-stack_pgdata:/data -v $(pwd):/backup alpine tar xzf /backup/pgdata-backup.tar.gz -C /data

Contacto y soporte

Si los problemas persisten:

1. Revisar la documentación oficial de SITMUN
2. Consultar los issues en GitHub
3. Contactar al equipo de soporte técnico
4. Proporcionar logs detallados del problema

Información útil para soporte

• Versión de Docker y Docker Compose
• Sistema operativo y versión
• Logs completos del error
• Pasos para reproducir el problema
• Configuración de red y firewall

Acerca de

Licencia

LICENCIA PÚBLICA DE LA UNIÓN EUROPEA v. 1.2

EUPL © Unión Europea 2007, 2016 La presente Licencia Pública de la Unión Europea (EUPL, por su sigla en inglés), se aplica a la obra (según se define más adelante) suministrada en las condiciones fijadas en la presente licencia. Queda prohibido cualquier uso de la obra distinto del autorizado por la presente licencia (en la medida en que tal uso esté protegido por un derecho del titular de los derechos de autor de la obra). La obra se suministra en las condiciones fijadas en la presente licencia cuando el licenciante (según se define más adelante) haya colocado la siguiente advertencia inmediatamente después de la mención a los derechos de autor de la obra:

Licencia cedida con arreglo a la EUPL

o haya expresado por cualquier otro medio su voluntad de conceder una licencia con arreglo a la EUPL.

1.Definiciones

En la presente licencia, se entenderá por:

• «licencia»:la presente licencia,
• «obra original»:la obra o el programa de ordenador distribuido o comunicado por el licenciante con arreglo a la presente licencia en forma de código fuente o, en su caso, de código ejecutable,
• «obras derivadas»:las obras o programas de ordenador que pudiera crear el licenciatario sobre la base de la obra original o de alguna de las modificaciones de esta. La presente licencia no define el grado de modificación o dependencia de la obra original necesario para clasificar una obra como derivada; dicho grado se determinará de acuerdo con la legislación sobre derechos de autor aplicable con arreglo al artículo 15,
• «obra»:la obra original o sus obras derivadas,
• «código fuente»:la forma de la obra legible por seres humanos que pueda ser estudiada y modificada más fácilmente,
• «código ejecutable»:cualquier código, en general compilado, destinado a ser interpretado como programa por un ordenador,
• «licenciante»:la persona física o jurídica que distribuye o comunica la obra con arreglo a la licencia,
• «colaborador»:la persona física o jurídica que modifica la obra con arreglo a la licencia o contribuye de cualquier otra manera a crear una obra derivada,
• «licenciatario»:la persona física o jurídica que hace un uso cualquiera de la obra en las condiciones fijadas en la licencia,
• «distribución» o «comunicación»:cualquier acto de venta, donación, préstamo, alquiler, distribución, comunicación, transmisión o cualquier otro acto de puesta a disposición, en línea o fuera de línea, de copias de la obra o de acceso a sus funcionalidades esenciales a otra persona física o jurídica.

2.Ámbito de los derechos otorgados por la Licencia

El licenciante concede al licenciatario una licencia de ámbito mundial, a título gratuito, no exclusiva y que el licenciatario puede subcontratar mientras sigan vigentes los derechos de autor sobre la obra original, y lo autoriza a:

• utilizar la obra en cualquier circunstancia y para cualquier uso,
• reproducir la obra,
• modificar la obra y realizar obras derivadas de la misma,
• comunicar al público la obra o copias de la misma, poner a su disposición o exhibir la obra o las copias y, en su caso, ejecutar públicamente la obra,
• distribuir la obra o copias de la misma,
• prestar y alquilar la obra o copias de la misma,
• subcontratar los derechos relativos a la obra o a las copias de la misma.

Dichos derechos se podrán ejercer a través de cualquier medio, soporte y formato, conocido en el presente o que pueda inventarse en el futuro, en la medida en que así lo permita la legislación aplicable. En los países cuyo ordenamiento contemple los derechos morales, el licenciante renunciará al ejercicio de los mismos en la medida en que lo permita la legislación, a fin de hacer efectiva la licencia de los derechos patrimoniales anteriormente enumerados. El licenciante cede al licenciatario, libre de cánones, los derechos de uso no exclusivos sobre cualquier patente de que sea titular, en la medida necesaria para que el licenciatario haga uso de los derechos sobre la obra otorgados por la presente licencia.

3.Comunicación del código fuente

El licenciante podrá suministrar la obra en forma de código fuente o código ejecutable. Si la suministrara en forma de código ejecutable, deberá facilitar además una copia legible automáticamente del código fuente de la obra junto con cada copia de la obra que distribuya, o bien indicar, en una advertencia inserta a continuación de la mención a los derechos de autor adjunta a la obra, un repositorio en el que se pueda acceder al código fuente fácilmente y de manera gratuita durante el período en que el licenciante siga distribuyendo o comunicando la obra.

4.Limitaciones a los derechos de autor

En ningún caso podrá interpretarse la presente licencia de modo que prive al licenciatario de los beneficios de los que pudiera disfrutar como consecuencia de las excepciones o limitaciones a los derechos exclusivos de los titulares de los derechos de la obra, de la extinción de dichos derechos o de cualquier otra limitación aplicable.

5.Obligaciones del licenciatario

La cesión de los derechos en virtud de la presente licencia queda supeditada a ciertas restricciones u obligaciones que habrá de respetar el licenciatario. Dichas obligaciones son:

• Derecho de atribución: El licenciatario deberá mantener íntegramente todas las advertencias y menciones a los derechos de autor, patentes o marcas registradas, así como las que se refieran a la licencia y a la exención de responsabilidad. El licenciatario deberá adjuntar copias de dichas advertencias y menciones y de la licencia con cada copia de la obra que distribuya o comunique. El licenciatario se responsabilizará de que cualquier obra derivada incluya una advertencia bien destacada declarando que se ha modificado la obra, y la fecha de modificación.

• Cláusula de «copyleft»: Si el licenciatario distribuyera o comunicara copias de la obra original o de obras derivadas basadas en la obra original, dicha distribución o comunicación deberá hacerse en las condiciones fijadas en la presente licencia o una versión posterior de la presente licencia, salvo si la obra original se distribuye expresamente solo bajo la presente versión de la licencia (por ejemplo, comunicando «EUPL v. 1.2 solamente». El licenciatario (ahora en su calidad de licenciante) no podrá ofrecer ni imponer condiciones adicionales sobre la obra o las obras derivadas que modifiquen o limiten las condiciones de la licencia.

• Cláusula de compatibilidad: Si el licenciatario distribuyera o comunicara obras derivadas o copias de estas últimas basadas a su vez en la obra y en otra obra licenciada bajo una licencia compatible, la distribución o comunicación podrán efectuarse con arreglo a las condiciones de dicha licencia compatible. A efectos de la presente cláusula, se entenderá por «licencia compatible» cualquiera de las licencias enumeradas en el apéndice adjunto a la presente licencia. En caso de que las obligaciones del licenciatario con arreglo a la licencia compatible estén en colisión con las derivadas de la presente licencia, prevalecerán las obligaciones de la licencia compatible.

-Suministro del código fuente: Cuando distribuya o comunique copias de la obra, el licenciatario deberá facilitar una copia del código fuente legible automáticamente o indicar un repositorio en que se pueda acceder al código fuente fácilmente y de manera gratuita durante el período en que siga distribuyendo o comunicando la obra.

• Salvaguardia de otros derechos: La presente licencia no faculta para utilizar los nombres comerciales, marcas de producto o de servicio o nombres del licenciante, excepto cuando ello, realizado en la medida de lo razonable y conforme a los usos habituales, sea necesario para indicar el origen de la obra y reproducir el contenido de la mención a los derechos de autor.

6.Secuencia de autoría

El licenciante original garantiza ser titular originario de los derechos de autor sobre la obra original objeto de la presente licencia o haberlos adquirido mediante la licencia correspondiente y estar facultado para otorgar licencias sobre tales derechos. Cada colaborador garantiza ser titular de los derechos de autor sobre las modificaciones que aporta a la obra o haberlos adquirido mediante la correspondiente licencia y estar facultado para otorgar licencias sobre tales derechos. Cada vez que el licenciatario acepta la licencia, el licenciante original y los colaboradores posteriores le otorgan una licencia sobre sus propias contribuciones a la obra en las condiciones fijadas en la presente licencia.

7.Exclusión de garantía

La obra se encuentra en proceso de elaboración, siendo objeto de continuas mejoras por parte de numerosos colaboradores. No es una obra acabada y, por tanto, puede contener defectos o fallos inherentes a este tipo de desarrollo. Por este motivo, la obra, en virtud de la licencia, se suministra «tal cual», sin garantías de ningún tipo, en particular, en una enumeración no exhaustiva, en cuanto a su comercialización, adecuación a un propósito determinado, ausencia de defectos o errores, exactitud y ausencia de infracción de los derechos de propiedad intelectual distintos de los derechos de autor según se afirma en el artículo 6 de la presente licencia. Esta exclusión de garantía forma parte esencial de la licencia y es condición para la cesión de cualquier derecho con respecto a la obra.

8.Exclusión de responsabilidad

Excepto en casos de dolo o de daños ocasionados directamente a personas físicas, el licenciante no será responsable de los daños y perjuicios de cualquier clase, directos o indirectos, materiales o morales, que pudieran derivarse de la licencia o del uso de la obra, en particular, en una enumeración no exhaustiva, de los daños y perjuicios por pérdida de buena reputación, paro técnico, avería o mal funcionamiento de equipos informáticos, pérdida de datos o cualquier perjuicio comercial, incluso si el licenciante conocía la posibilidad de dichos daños. No obstante, el licenciante será responsable, de acuerdo con las normas legales que regulen la responsabilidad por los daños causados por productos, en la medida en que dichas normas sean aplicables a la obra.

9.Acuerdos adicionales

Al distribuir la obra, el licenciatario podrá suscribir un acuerdo adicional que defina obligaciones o servicios compatibles con la presente licencia. No obstante, al aceptar tales obligaciones, el licenciatario actuará únicamente en nombre propio y bajo su exclusiva responsabilidad, y nunca en nombre del licenciante original ni de ningún otro colaborador, y ello a condición de que acceda a indemnizar, defender y amparar a todo colaborador frente a cualquier responsabilidad en que este pudiera incurrir y frente a las reclamaciones que pudieran presentarse contra él por haber aceptado el licenciatario la mencionada garantía o responsabilidad adicional.

10.Aceptación de la licencia

Lo dispuesto en la presente licencia puede aceptarse haciendo clic en el icono «Aceptar» situado en la parte inferior de la ventana en que aparece el texto de la presente licencia o manifestando el consentimiento de cualquier otra forma similar, de conformidad con lo previsto en la legislación aplicable. Haciendo clic en dicho icono, se expresa la aceptación inequívoca e irrevocable de la presente licencia y de todo su contenido. Asimismo, el licenciatario acepta irrevocablemente la presente licencia y todas sus condiciones por el mero hecho de ejercer cualquiera de los derechos que le otorga el artículo 2 de la presente licencia, tales como el uso de la obra, la creación de una obra derivada o la distribución o comunicación de la obra o de copias de la misma.

11.Información al público

En caso de que el licenciatario proceda a la distribución o comunicación de la obra por medios electrónicos (por ejemplo, ofreciendo la descarga de la obra a distancia), el canal o medio de distribución (por ejemplo, un sitio web) deberá facilitar al público, como mínimo, la información exigida por la legislación aplicable acerca del licenciante, la licencia y la manera en que el licenciatario puede acceder a dichos datos, aceptarlos, conservarlos y reproducirlos.

12.Extinción de la licencia

La licencia y los derechos otorgados a su amparo se extinguirán automáticamente si el licenciatario incumple alguna de las condiciones de la licencia. Tal extinción no supondrá, sin embargo, la de las licencias de que disfruten las personas que hayan recibido la obra del licenciatario en virtud de la licencia, siempre que dichas personas sigan cumpliendo plenamente las condiciones de la licencia.

13.Varios

No obstante lo dispuesto en el artículo 9, la licencia representará la totalidad del acuerdo entre las partes en cuanto a la obra. La eventual invalidez o ineficacia de alguna disposición de la presente licencia con arreglo a la legislación vigente no afectará a la validez o eficacia general de la licencia. En tales casos, la disposición se interpretará o reformulará según proceda para hacerla válida y eficaz. La Comisión Europea podrá publicar otras versiones lingüísticas o nuevas versiones de la presente licencia o versiones actualizadas del apéndice en la medida en que resulte necesario y razonable y sin reducir el ámbito de los derechos concedidos por la licencia. Las nuevas versiones de la licencia se publicarán con un número de versión único. Todas las versiones lingüísticas de la presente licencia aprobadas por la Comisión Europea tienen idéntico valor. Las partes pueden utilizar la versión lingüística de su preferencia.

14.Tribunales competentes

Sin perjuicio de lo dispuesto en un acuerdo específico entre las partes,

• los litigios relativos a la interpretación de la presente licencia que se planteen entre las instituciones, órganos y organismos de la Unión Europea, en calidad de licenciante, y un licenciatario, se someterán a la jurisdicción del Tribunal de Justicia de la Unión Europea, con arreglo al artículo 272 del Tratado de Funcionamiento de la Unión Europea;
• los litigios relativos la interpretación de la presente licencia que se planteen entre otras partes se someterán a la jurisdicción exclusiva del tribunal que sea competente en el lugar en que resida o ejerza su actividad principal el licenciante.

15.Legislación aplicable

Sin perjuicio de lo dispuesto en un acuerdo específico entre las partes,

• la presente licencia se regirá por la legislación del Estado miembro de la Unión Europea en el que tenga su sede, resida o tenga su domicilio social el licenciante;
• la presente licencia se regirá por el Derecho belga si el licenciante no tiene sede, residencia ni domicilio social en un Estado miembro de la Unión Europea.

Apéndice

Son «licencias compatibles» con arreglo al artículo 5 de la EUPL:

• GNU General Public License (GPL) v. 2, v. 3
• GNU Affero General Public License (AGPL) v. 3
• Open Software License (OSL) v. 2.1, v. 3.0
• Eclipse Public License (EPL) v. 1.0
• CeCILL v. 2.0, v. 2.1
• Mozilla Public Licence (MPL) v. 2
• GNU Lesser General Public Licence (LGPL) v. 2.1, v. 3
• Creative Commons Attribution-ShareAlike v. 3.0 Unported (CC BY-SA 3.0) para obras que no sean programas informáticos
• European Union Public Licence (EUPL) v. 1.1, v. 1.2
• Québec Free and Open-Source Licence - Reciprocity (LiLiQ-R) or Strong Reciprocity (LiLiQ-R+).

La Comisión Europea podrá actualizar el presente apéndice a versiones posteriores de las licencias mencionadas sin presentar una nueva versión de la EUPL, siempre que contemplen los derechos reconocidos en el artículo 2 de la presente licencia y protejan de la apropiación exclusiva el código fuente cubierto. Cualquier otra modificación o adición al presente apéndice exigirá la presentación de una nueva versión de la EUPL.

19.5.2017 L 128/64 Diario Oficial de la Unión Europea ES

Información de contacto

Comité técnico

• Fina Sáez saezbj@diba.cat y Montse Marco marcosm@diba.cat - Diputació de Barcelona.
• Marta Codinachs codinachssm@diba.cat - Diputació de Barcelona.
• Ricard Cots cartografia@cime.es - Consell Insular de Menorca.
• Marc Rosés cartografia@cime.es - SILME.
• Miquel Latorre mlatorre@diputaciolleida.cat - Diputació de Lleida.

Equipo de coordinación técnica

La labor principal de este equipo es mantener una visión global del proyecto y coordinar a las distintas empresas y administraciones involucradas desde el punto de vista técnico. Entre sus tareas están la documentación técnica, la validación de propuestas y entregables, el asesoramiento tecnológico al comité técnico del proyecto, etc.

• Rubén Béjar rbejar@unizar.es y Francisco Javier Lopez Pellicer fjlopez@unizar.es - Universidad Zaragoza.

La Red Europea SITMUN

Toda la información sobre la Red Europea SITMUN está disponible en http://www.sitmun.org.

Ended: Acerca de