Skip to main content

ADR 019: Select Geoportal Component

Date: 2025-11-06

Status: Reviewed

Decision Makers: @luckey @DerLinne

Context​

CIVITAS/CORE needs a central geoportal component for browser-based visualization and exploration of geospatial data. The component must integrate well with the platform architecture, especially with OGC-based interfaces such as those exposed by GeoServer and related platform services.

The geoportal is part of the presentation layer. It should provide standard map functionality out of the box, allow configuration instead of extensive custom development, and be mature enough for productive use in public-sector contexts.

For CIVITAS/CORE V1, Masterportal was already used successfully for this purpose. Masterportal is an established open-source geoportal framework with strong support for common geospatial standards and a proven deployment model in browser-based environments.

The decision to keep using Masterportal should therefore be made explicit for CIVITAS/CORE V2 instead of re-implementing geoportal functionality from scratch or selecting a less proven alternative.

Checked Architecture Principles​

  • [partial] Model-centric data flow
  • [full] Distributed architecture with unified user experience
  • [full] Modular design
  • [full] Integration capability through defined interfaces
  • [full] Open source as the default
  • [partial] Cloud-native architecture
  • [full] Prefer standard solutions over custom development
  • [full] Self-contained deployment
  • [partial] Technological consistency to ensure maintainability
  • [partial] Multi-tenancy
  • [partial] Security by design

Comments on partial ratings:

  • Model-centric data flow: Masterportal is configuration-driven, but its runtime configuration is a product-specific artifact. CIVITAS/CORE domain models should remain the authoritative source, with Masterportal configuration derived from them where needed.
  • Cloud-native architecture: Masterportal can be deployed as a containerized web application inside Kubernetes, but it is primarily a browser client and not a cloud-native control-plane component by itself.
  • Technological consistency to ensure maintainability: Masterportal introduces its own frontend stack and UI patterns. This is acceptable because it is scoped to the geoportal capability and avoids a much larger custom implementation effort.
  • Multi-tenancy: Tenant separation is possible through tenant-specific configuration, branding, and deployment patterns, but multi-tenancy is not provided as a native Masterportal platform concept.
  • Security by design: Masterportal can be integrated into a secure platform setup, but access control, authentication, and secure exposure of geodata services must still be enforced by surrounding CIVITAS/CORE components and infrastructure.

Decision​

Masterportal V3 is selected as the standard geoportal component for CIVITAS/CORE V2.

Reasons:

  • It is a mature and proven open-source solution for browser-based map visualization.
  • It supports the OGC-oriented integration approach of CIVITAS/CORE and fits well with standardized geospatial service interfaces.
  • It was already used successfully in CIVITAS/CORE V1, which reduces adoption risk and implementation effort.
  • It allows the project to focus on platform integration, configuration, and user workflows instead of building and maintaining a custom geoportal frontend.

Masterportal should be used as a replaceable presentation component. CIVITAS/CORE-specific logic should remain outside the component where possible, and integration should happen primarily through standard interfaces and configuration.

Consequences​

  • The presentation layer for map-based exploration in CIVITAS/CORE will use Masterportal as the default geoportal runtime.
  • Geo-related backend services should expose standards-based interfaces that can be consumed directly by Masterportal.
  • Tenant-specific map configurations, layer definitions, branding, and navigation concepts must be managed explicitly.
  • Custom geoportal functionality should only be added when it cannot reasonably be achieved through Masterportal configuration or extension mechanisms.
  • The platform avoids the initial and long-term cost of building a dedicated geoportal client from scratch, but accepts dependency on the Masterportal ecosystem and release model.

Alternatives​

  • Custom web map client based on OpenLayers, Leaflet, or MapLibre: Discarded because it would shift substantial effort into implementing standard geoportal functionality, configuration handling, and long-term maintenance that Masterportal already provides.
  • Using only generic backend UIs such as GeoServer administration or preview screens: Discarded because these interfaces do not provide a coherent geoportal user experience for end users and are not intended as the central presentation component.
  • Selecting a different geoportal framework: Discarded for now because Masterportal already has project experience, proven public-sector usage, and a better fit-to-effort ratio than re-evaluating the market without a strong functional gap.

See also​