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 actualmente desplegadas en Heroku (servidor de pruebas y preproducción). También se pueden consultar en https://sitmun-backend-core.herokuapp.com/swagger-ui/index.html.
• 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 

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.
• Una cuenta de GitHub con la que crear un token de acceso personal.
• 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 11 SE (LTS).
• Node.js. Puedes descargar Node.js desde el sitio oficial: https://nodejs.org/
  • El visor de mapas requiere Node.js con una versión compatible con Angular 16, que puede ser ^16.14.0 || ^18.10.0.
  • El administrador requiere Node.js con una versión compatible con Angular 10, que puede ser ^12.11.1.
• 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 (Postgres u Oracle) en el caso de backend. El soporte de Postgres es estable, mientras que el soporte de Oracle requiere de pruebas adicionales.
• 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 11 SE (LTS).
• Node.js. Puedes descargar Node.js desde el sitio oficial: https://nodejs.org/
  • El visor de mapas requiere Node.js con una versión compatible con Angular 16, que puede ser ^16.14.0 || ^18.10.0.
  • El administrador requiere Node.js con una versión compatible con Angular 10, que puede ser ^12.11.1.
• 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 (Postgres u Oracle) en el caso de backend. El soporte de Postgres es estable, mientras que el soporte de Oracle requiere de pruebas adicionales.
• 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).

Instalación

DockerFuente

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
• proxy, que expone el API proxy-middleware de SITMUN y que se comunica con el servicio backend
• persistence: base de datos PostgreSQL que almacena los datos en el volumen pgdata.

Para fines de prueba, el uso del proxy está controlado por la variable de entorno sitmun.proxy.force en backend, que por defecto es true.

block-beta
columns 5

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

space:5

persistence[("<b>persistence</b><br>postgres<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" --> persistence

Pasos de instalación

Para instalar SITMUN, sigue estos pasos:

1. Clona el repositorio y los proyectos anidados de SITMUN:

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

2. Cambia al directorio del repositorio:

   cd sitmun-application-stack
   

3. Crea un nuevo archivo llamado .env dentro del directorio. Abre el archivo .env en un editor de texto y agrega tu token de acceso personal de GitHub (GITHUB_TOKEN) en el siguiente formato:

   GITHUB_TOKEN=tu_token_de_acceso_personal
   

4. Inicia la plataforma SITMUN:

   docker compose up
   

   Este comando construirá e iniciará todos los servicios definidos en el archivo docker-compose.yml.

5. Accede a la aplicación del visor de SITMUN en http://localhost:9000/viewer. Usa el acceso público que no requiere autenticación.

6. Accede a la aplicación administrativa de SITMUN en http://localhost:9000/admin. Esto requiere autenticación. El nombre de usuario predeterminado es admin y la contraseña predeterminada es admin.

Configuración

Las variables de entorno se definen en el archivo .env.

Las siguientes variables de entorno están disponibles:

• GITHUB_TOKEN: Token de acceso personal de GitHub (clásico). El token es necesario para obtener paquetes npm de GitHub Packages.

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. Actualmente, se recomienda solo usar en modo de prueba heroku-dev-full que requiere de una base de datos postgres.

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. Obtiene un token de GitHub para trabajar con el registro de npm de GitHub Packages.

3. Desde la consola de comandos ejecuta el siguiente comando para autenticarte en el registro de GitHub Packages de npm:

   npm set //npm.pkg.github.com/:_authToken <token>
   

   Sustituye <token> por el token que has obtenido en el paso anterior.

4. 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.

5. 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. Obtiene un token de GitHub para trabajar con el registro de npm de GitHub Packages.

3. Desde la consola de comandos ejecuta el siguiente comando para autenticarte en el registro de GitHub Packages de npm:

   npm set //npm.pkg.github.com/:_authToken <token>
   

   Sustituye <token> por el token que has obtenido en el paso anterior.

4. 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.

5. 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.

Creando una aplicación

En desarrollo

Esta sección está siendo actualizada.

Personalización

En desarrollo

Esta sección está siendo actualizada.

Licencia

European Union Public Licence V. 1.2

EUPL © the European Union 2007, 2016

This European Union Public Licence (the ‘EUPL’) applies to the Work (as defined below) which is provided under the terms of this Licence. Any use of the Work, other than as authorised under this Licence is prohibited (to the extent such use is covered by a right of the copyright holder of the Work).

The Work is provided under the terms of this Licence when the Licensor (as defined below) has placed the following notice immediately following the copyright notice for the Work: “Licensed under the EUPL”, or has expressed by any other means his willingness to license under the EUPL.

1. Definitions

In this Licence, the following terms have the following meaning: — ‘The Licence’: this Licence. — ‘The Original Work’: the work or software distributed or communicated by the Licensor under this Licence, available as Source Code and also as Executable Code as the case may be. — ‘Derivative Works’: the works or software that could be created by the Licensee, based upon the Original Work or modifications thereof. This Licence does not define the extent of modification or dependence on the Original Work required in order to classify a work as a Derivative Work; this extent is determined by copyright law applicable in the country mentioned in Article 15. — ‘The Work’: the Original Work or its Derivative Works. — ‘The Source Code’: the human-readable form of the Work which is the most convenient for people to study and modify.

— ‘The Executable Code’: any code which has generally been compiled and which is meant to be interpreted by a computer as a program. — ‘The Licensor’: the natural or legal person that distributes or communicates the Work under the Licence. — ‘Contributor(s)’: any natural or legal person who modifies the Work under the Licence, or otherwise contributes to the creation of a Derivative Work. — ‘The Licensee’ or ‘You’: any natural or legal person who makes any usage of the Work under the terms of the Licence. — ‘Distribution’ or ‘Communication’: any act of selling, giving, lending, renting, distributing, communicating, transmitting, or otherwise making available, online or offline, copies of the Work or providing access to its essential functionalities at the disposal of any other natural or legal person.

1. Scope of the rights granted by the Licence

The Licensor hereby grants You a worldwide, royalty-free, non-exclusive, sublicensable licence to do the following, for the duration of copyright vested in the Original Work:

— use the Work in any circumstance and for all usage, — reproduce the Work, — modify the Work, and make Derivative Works based upon the Work, — communicate to the public, including the right to make available or display the Work or copies thereof to the public and perform publicly, as the case may be, the Work, — distribute the Work or copies thereof, — lend and rent the Work or copies thereof, — sublicense rights in the Work or copies thereof.

Those rights can be exercised on any media, supports and formats, whether now known or later invented, as far as the applicable law permits so.

In the countries where moral rights apply, the Licensor waives his right to exercise his moral right to the extent allowed by law in order to make effective the licence of the economic rights here above listed.

The Licensor grants to the Licensee royalty-free, non-exclusive usage rights to any patents held by the Licensor, to the extent necessary to make use of the rights granted on the Work under this Licence.

1. Communication of the Source Code

The Licensor may provide the Work either in its Source Code form, or as Executable Code. If the Work is provided as Executable Code, the Licensor provides in addition a machine-readable copy of the Source Code of the Work along with each copy of the Work that the Licensor distributes or indicates, in a notice following the copyright notice attached to the Work, a repository where the Source Code is easily and freely accessible for as long as the Licensor continues to distribute or communicate the Work.

1. Limitations on copyright

Nothing in this Licence is intended to deprive the Licensee of the benefits from any exception or limitation to the exclusive rights of the rights owners in the Work, of the exhaustion of those rights or of other applicable limitations thereto.

1. Obligations of the Licensee

The grant of the rights mentioned above is subject to some restrictions and obligations imposed on the Licensee. Those obligations are the following:

Attribution right: The Licensee shall keep intact all copyright, patent or trademarks notices and all notices that refer to the Licence and to the disclaimer of warranties. The Licensee must include a copy of such notices and a copy of the Licence with every copy of the Work he/she distributes or communicates. The Licensee must cause any Derivative Work to carry prominent notices stating that the Work has been modified and the date of modification.

Copyleft clause: If the Licensee distributes or communicates copies of the Original Works or Derivative Works, this Distribution or Communication will be done under the terms of this Licence or of a later version of this Licence unless the Original Work is expressly distributed only under this version of the Licence — for example by communicating ‘EUPL v. 1.2 only’. The Licensee (becoming Licensor) cannot offer or impose any additional terms or conditions on the Work or Derivative Work that alter or restrict the terms of the Licence.

Compatibility clause: If the Licensee Distributes or Communicates Derivative Works or copies thereof based upon both the Work and another work licensed under a Compatible Licence, this Distribution or Communication can be done under the terms of this Compatible Licence. For the sake of this clause, ‘Compatible Licence’ refers to the licences listed in the appendix attached to this Licence. Should the Licensee's obligations under the Compatible Licence conflict with his/her obligations under this Licence, the obligations of the Compatible Licence shall prevail.

Provision of Source Code: When distributing or communicating copies of the Work, the Licensee will provide a machine-readable copy of the Source Code or indicate a repository where this Source will be easily and freely available for as long as the Licensee continues to distribute or communicate the Work.

Legal Protection: This Licence does not grant permission to use the trade names, trademarks, service marks, or names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the copyright notice.

1. Chain of Authorship

The original Licensor warrants that the copyright in the Original Work granted hereunder is owned by him/her or licensed to him/her and that he/she has the power and authority to grant the Licence.

Each Contributor warrants that the copyright in the modifications he/she brings to the Work are owned by him/her or licensed to him/her and that he/she has the power and authority to grant the Licence.

Each time You accept the Licence, the original Licensor and subsequent Contributors grant You a licence to their contributions to the Work, under the terms of this Licence.

1. Disclaimer of Warranty

The Work is a work in progress, which is continuously improved by numerous Contributors. It is not a finished work and may therefore contain defects or ‘bugs’ inherent to this type of development.

For the above reason, the Work is provided under the Licence on an ‘as is’ basis and without warranties of any kind concerning the Work, including without limitation merchantability, fitness for a particular purpose, absence of defects or errors, accuracy, non-infringement of intellectual property rights other than copyright as stated in Article 6 of this Licence.

This disclaimer of warranty is an essential part of the Licence and a condition for the grant of any rights to the Work.

1. Disclaimer of Liability

Except in the cases of wilful misconduct or damages directly caused to natural persons, the Licensor will in no event be liable for any direct or indirect, material or moral, damages of any kind, arising out of the Licence or of the use of the Work, including without limitation, damages for loss of goodwill, work stoppage, computer failure or malfunction, loss of data or any commercial damage, even if the Licensor has been advised of the possibility of such damage. However, the Licensor will be liable under statutory product liability laws as far such laws apply to the Work.

1. Additional agreements

While distributing the Work, You may choose to conclude an additional agreement, defining obligations or services consistent with this Licence. However, if accepting obligations, You may act only on your own behalf and on your sole responsibility, not on behalf of the original Licensor or any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against such Contributor by the fact You have accepted any warranty or additional liability.

1. Acceptance of the Licence

The provisions of this Licence can be accepted by clicking on an icon ‘I agree’ placed under the bottom of a window displaying the text of this Licence or by affirming consent in any other similar way, in accordance with the rules of applicable law. Clicking on that icon indicates your clear and irrevocable acceptance of this Licence and all of its terms and conditions.

Similarly, you irrevocably accept this Licence and all of its terms and conditions by exercising any rights granted to You by Article 2 of this Licence, such as the use of the Work, the creation by You of a Derivative Work or the Distribution or Communication by You of the Work or copies thereof.

1. Information to the public

In case of any Distribution or Communication of the Work by means of electronic communication by You (for example, by offering to download the Work from a remote location) the distribution channel or media (for example, a website) must at least provide to the public the information requested by the applicable law regarding the Licensor, the Licence and the way it may be accessible, concluded, stored and reproduced by the Licensee.

1. Termination of the Licence

The Licence and the rights granted hereunder will terminate automatically upon any breach by the Licensee of the terms of the Licence. Such a termination will not terminate the licences of any person who has received the Work from the Licensee under the Licence, provided such persons remain in full compliance with the Licence.

1. Miscellaneous

Without prejudice of Article 9 above, the Licence represents the complete agreement between the Parties as to the Work.

If any provision of the Licence is invalid or unenforceable under applicable law, this will not affect the validity or enforceability of the Licence as a whole. Such provision will be construed or reformed so as necessary to make it valid and enforceable.

The European Commission may publish other linguistic versions or new versions of this Licence or updated versions of the Appendix, so far this is required and reasonable, without reducing the scope of the rights granted by the Licence. New versions of the Licence will be published with a unique version number.

All linguistic versions of this Licence, approved by the European Commission, have identical value. Parties can take advantage of the linguistic version of their choice.

1. Jurisdiction

Without prejudice to specific agreement between parties, — any litigation resulting from the interpretation of this License, arising between the European Union institutions, bodies, offices or agencies, as a Licensor, and any Licensee, will be subject to the jurisdiction of the Court of Justice of the European Union, as laid down in article 272 of the Treaty on the Functioning of the European Union, — any litigation arising between other parties and resulting from the interpretation of this License, will be subject to the exclusive jurisdiction of the competent court where the Licensor resides or conducts its primary business.

1. Applicable Law

Without prejudice to specific agreement between parties, — this Licence shall be governed by the law of the European Union Member State where the Licensor has his seat, resides or has his registered office, — this licence shall be governed by Belgian law if the Licensor has no seat, residence or registered office inside a European Union Member State.

Appendix

‘Compatible Licences’ according to Article 5 EUPL are: — 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) for works other than software — 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+)

— The European Commission may update this Appendix to later versions of the above licences without producing a new version of the EUPL, as long as they provide the rights granted in Article 2 of this Licence and protect the covered Source Code from exclusive appropriation. — All other changes or additions to this Appendix require the production of a new EUPL version.

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

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.

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

Documentación en desarrollo

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	Noviembre 2024
Próxima modificación	Marzo 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 Ver ejemplo
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 Ver ejemplo
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, Spring Boot se usa en el tier web, y una base de datos relacional (Oracle o PostgreSQL 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": "wms",
  "exp": 1623340800,
  "payload": {
    "uri": "https://geoserveis.icgc.cat/icgc_bm5m/wms/service",
    "method": "GET",
    "vary": [
      "BBOX"
    ],
    "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.

Explorar API de Autenticación

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.

Explorar API de Configuración y Autorización

API de Proxy

La API de Proxy 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.

Explorar API de Proxy

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.

Explorar API de Administració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
sitmum.authentication.ldap.username	El nombre de usuario a utilizar cuando se autentique con el servidor LDAP	nulo
sitmum.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.config-response-validity-in-secons	Duración máxima del token de acceso que admite la API	3600
sitmun.authentication.middleware.secret	Token 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.force	Fuerza el uso del proxy de SITMUN	false
sitmun.proxy.url	Localización del proxy de SITMUN

Proxy

Propiedad	Descripción	Valor por defecto
sitmun.config.url	Ruta al endpoint de configuración del proxy en la API de configuración y autorización
sitmun.authentication.middleware.secret	Token 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.	https://sitmun-backend-core.herokuapp.com

Administrador

Propiedad	Descripción	Valor por defecto
apiBaseURL	La URL pública donde se despliega el backend.	https://sitmun-backend-core.herokuapp.com

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, y el proyecto hace las pruebas de preproducción en Heroku. 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 11, usando Spring Boot 2.4.3. El desarrollo de las aplicaciones de frontend se hace con TypeScript y Angular 16.0.0. En general, se usan las últimas versiones de las dependencias, pero hay alguna excepción como el Administrador, que está desarrollado en Angular 10.1.6.

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 11 y Spring Boot. Más información.
• sitmun-proxy-middleware: Proxy a servicios web restringidos y middleware a bases de datos. Desarrollado en Java 11 y Spring Boot. 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

Demostradores

Pruebas y preproducción

Aplicación de administración

Una aplicación de administración con datos de pruebas.

Enlace directo

Visor de mapas

Un visor de mapas que utiliza los datos gestionados por la aplicación de administración.

Enlace directo.

Ended: Demostradores

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.