5G “On the Map”

From Raw Measurements to Meaningful Geovisualization

A map may appear to be one of the most straightforward elements of a network analytics platform. Data is collected, placed on a geographical layer, assigned a color, and displayed to the user.

In practice, the difficult part is not drawing the map. It is deciding what each element should mean, how millions of irregular measurements should be aggregated, how results should change across zoom levels, and how complex radio data can be presented without forcing the user to interpret the underlying technical structures.

This article presents the results of Task 2 carried out under project FEMA.01.01-IP.01-02E5/24, titled “Optimization and improvement of a platform for analysis and quality assessment of services in next-generation 5G mobile networks”.

Task 2 – Development of new methods for geovisualization of user data on the RFBENCHMARK portal – was conducted as industrial research focused on the relationship between spatial data processing, user experience, backend architecture, and client-side map rendering.

Its purpose was not simply to redesign the existing map or introduce a new visual style. The objective was to develop and experimentally validate a new method of presenting crowdsourced mobile network data: one based on hierarchical H3 spatial aggregation, GeoJSON data structures, a dedicated API layer, and an interactive frontend capable of supporting rankings, filters, local details, and multiple map resolutions.

The key question was whether complex radio and active-test data could be transformed into an interface that is technically consistent, responsive, and understandable to users who should not need to know how H3 indexing, SQL queries, or spatial aggregation work.

Questions and hypotheses

The research was organized around several practical questions:

• Can irregular crowdsourced measurements be converted into stable spatial units that remain comparable across different map scales?
• Can the map communicate which operator performs best in a given area without requiring the user to interpret several unrelated color scales and KPI definitions simultaneously?
• Can the same data model support multiple H3 resolutions, MNO and RAT filtering, operator rankings, individual hexagon details, and both desktop and mobile layouts?
• Finally, can the data, API, and frontend layers be separated clearly enough for the visualization method to remain consistent as the platform evolves?

Answering these questions required more than preparing a graphical mock-up. We needed to analyze the baseline solution, examine the characteristics of the source data, design a new interaction model, prepare an H3 aggregation algorithm, build API components, implement a frontend prototype, and verify the entire processing chain in a controlled laboratory environment.

Why raw measurements do not automatically create a useful map

Crowdsourced mobile network data provides a highly detailed picture of real-world network usage. It may contain active test results such as download speed, upload speed, and latency, as well as radio parameters, operator identifiers, mobile technologies, GPS coordinates, timestamps, and device-related information.

This detail is valuable, but it also creates several analytical problems.

Measurements are not distributed evenly. Some roads, cities, and locations contain large numbers of samples, while other areas may have only a few observations. Results are collected using different devices and under changing radio conditions. GPS positions contain noise, individual measurements may be duplicated or invalid, and extreme values may distort the interpretation of an area.

Displaying such records directly as individual points does not solve the problem. At a larger scale, thousands of overlapping points become unreadable. At the same time, rendering and processing them may place unnecessary load on the browser and backend infrastructure.

The baseline analysis also showed that the previous map model had evolved into a strongly coupled, request-driven architecture. User interactions such as panning the map, changing the zoom level, or applying a filter could initiate new calculations directly on the source database. There was no dedicated analytical layer, no consistent preaggregation model, and limited use of caching or reusable processed datasets.

This affected both system performance and user experience. The map could display information, but it did not provide a sufficiently clear hierarchy between the main spatial message, detailed KPIs, filters, rankings, and data reliability.

The problem could therefore not be solved by adjusting colors or rearranging interface controls. It required a different method of preparing and communicating the data.

Designing the meaning of the map before implementing it

The first major stage of Task 2 was the development of a graphical prototype in Figma, covering both desktop and mobile interaction models.

One of the most important research decisions was to adopt an operator-dominance model.

In a conventional thematic map, a color may represent the value of a selected KPI. This approach works well when a single parameter is being analyzed, but becomes less intuitive when users need to compare operators across metrics with different meanings.

Higher download and upload values are usually better. Lower latency is better. Radio signal parameters use different scales and require additional technical knowledge. If the meaning of the map color changes every time a user selects a different metric, the visual language becomes unstable.

In the new model, the primary color of an H3 hexagon identifies the leading operator in that area. Detailed values such as ping, signal level, download, and upload remain available in the operator ranking and in the detailed view of the selected hexagon.

This creates a clear hierarchy:

• the map provides a rapid spatial overview,
• the ranking explains the comparative result,
• and the selected-hexagon view provides local KPI details.

The prototype also introduced a consistent operator legend, location search, RAT and operator filters, map controls, loading states, empty-result states, and dedicated mobile layouts.

The mobile interface was not treated as a reduced desktop screen. Instead, information was revealed progressively: a compact ranking remained available without covering the map, while filters and detailed results could be expanded when needed.

The prototype therefore became more than a visual concept. It defined the data and interaction contract that the backend and frontend would later have to implement.

From GPS coordinates to a hierarchical H3 model

The analytical part of the research focused on converting source measurements into a spatial structure suitable for interactive visualization.

Several aggregation approaches were examined, including coordinate rounding, regular square grids, geohash, and conventional hexagonal grids. H3 indexing was selected because it combines hexagonal spatial representation with a hierarchical addressing system.

Each measurement can be assigned to an H3 cell, and the same area can be represented at different resolutions. This makes it possible to display larger aggregated regions when the user views a broad territory and progressively increase detail as the map is zoomed in.

Before aggregation, the sample data was subjected to validation and cleaning. The process included identifying invalid coordinates, incorrect operator codes, unsupported radio technologies, improper signal values, repeated samples, and observations that could negatively affect aggregate stability.

The prepared pipeline then:

1. assigned measurements to H3 indexes at multiple resolutions,
2. aggregated active-test and radio parameters within individual cells,
3. calculated operator-related statistics and rankings,
4. generated hexagon geometries using H3 and PostGIS,
5. and serialized the results into structures suitable for GeoJSON publication.

This allowed the visualization layer to work with spatially organized objects rather than large sets of individual measurements.

H3 was therefore not used merely to draw hexagonal shapes. It became the indexing and aggregation model connecting the source data, database structures, API responses, and frontend rendering.

The API as a contract between analytics and visualization

A dedicated backend API was prepared to supply the frontend application with data in a form consistent with the new visualization method.

The API included separate functional areas for:

• map data in GeoJSON format,
• operator rankings for the current map area,
• available RAT and operator filters,
• and detailed data for an individual H3 cell.

The current map bounding box was used to determine the requested area, while the spatial extent could also influence the H3 resolution selected for the response.

This separation was important because the frontend was not intended to perform complex aggregation independently. Heavy spatial and analytical operations remained in the database and backend layers. The client application received prepared structures and focused on rendering, interaction, and state management.

The API model also included response compression, caching mechanisms based on Redis, authorization controls, and Prometheus metrics used to observe request behavior and responsiveness.

As a result, the map, ranking, and detailed panel could all be supplied by the same analytical model. The leading operator shown by the color of a hexagon and the operator order shown in the ranking were no longer separate interpretations of the data.

They became two views of the same result.

Building the client-side visualization layer

The frontend prototype was prepared as a React/Vite application using TypeScript, Redux Toolkit, RTK Query, MapLibre, and a component-based interface structure.

Its role was to verify whether aggregated H3 data could be presented as a complete user interaction model rather than as an isolated technical demonstration.

The application rendered GeoJSON hexagons on the map, refreshed data when the visible area changed, supported operator and radio technology filters, displayed rankings for the current bounding box, and allowed users to select an individual H3 cell to view local results.

It also included desktop and mobile layouts, loading indicators, error handling, empty-result states, operator legends, and controlled interface labels in Polish and English.

From the user’s perspective, the technical complexity remained hidden. Moving the map, changing the zoom level, selecting LTE or 5G, filtering an operator, or clicking a hexagon were presented as natural map interactions.

The application translated those interactions into state changes and API requests without requiring the user to understand H3 indexes, GeoJSON structures, database queries, or endpoint parameters.

This was a central part of the research result. The new method was not considered complete merely because a backend could generate aggregated data. It also had to be demonstrated that the data could be interpreted through a coherent visual and interactive language.

Verifying the concept in a laboratory architecture

The final stage of Task 2 examined how the developed data model, API, and frontend could operate within a new laboratory architecture.

The infrastructure results developed during Task 1 were used as a foundation. The environment included OVH resources, Terraform, Ansible, Docker Swarm, PostgreSQL/PostGIS, Redis, Prometheus, Geo API components, and the React/Vite frontend.

The focus, however, was different from Task 1. Instead of validating cluster resilience as the primary objective, Task 2 concentrated on relocating measurement data, preparing H3 tables and aggregates, indexing spatial structures, serving map and ranking queries, and examining the influence of caching on API responsiveness.

Both two-server and extended three-server variants were considered to evaluate the separation of entry, application, and data layers.

The environment was strictly experimental. It was not intended to become a production deployment or a finished commercial platform. Its purpose was to provide controlled conditions in which the complete geovisualization chain could be tested and documented.

Milestone validation: from an HTTP request to a rendered map

The formal milestone for Task 2 was the achievement of a working client-side geovisualization layer presenting H3 clusters created from aggregated radio data.

The validation covered the entire path from source data to browser rendering. The tested scenario required:

• radio data originating from an SQL database,
• data supplied in GeoJSON format,
• rendering of H3 hexagonal clusters,
• support for at least three H3 resolutions,
• filtering by mobile network operator and radio access technology,
• and loading and rendering the generated map in under 90 seconds.

Manual testing was conducted using Mozilla Firefox, Google Chrome, and Apple Safari. In accordance with the research plan, the milestone was considered achieved when at least 80% of the manual tests were completed successfully across the three client browsers.

The validation confirmed that these conditions were met.

This result should not be interpreted as the launch of a finished production map. It confirms that the proposed method—covering spatial aggregation, GeoJSON delivery, filtering, ranking, and client-side rendering—works as a complete laboratory prototype and can form the basis for subsequent development.

What was delivered—and what does it mean for network analytics?

Task 2 resulted in a coherent analytical and technological chain that:

1. transforms irregular point measurements into hierarchical H3 aggregates,
2. introduces a stable visual model based on operator dominance,
3. connects map data, rankings, filters, and local details through a consistent API contract,
4. supports desktop and mobile interaction models,
5. and verifies the full path from SQL-origin data to an interactive browser-rendered map.

For network analytics, the practical significance is clear.

Collecting more data does not automatically produce more knowledge. The value appears only when measurements can be organized spatially, compared consistently, and presented in a way that allows users to identify patterns without first reconstructing the analytical logic behind the interface.

The map therefore becomes more than a visualization layer. It becomes a method for translating complex radio and service-quality data into information that can be explored, compared, and understood.

Next step

The completion of Task 2 confirms that the platform’s measurement data can be transformed into a consistent interactive geovisualization model.

Further work will require additional validation on larger and more diverse datasets, optimization for production-scale loads, integration with the remaining platform components, and continued development of the mechanisms that prepare network data for analysis.

The research result provides the conceptual and technical foundation for that work: a map in which the user sees a clear spatial message, while the complexity of aggregation, indexing, APIs, and radio data remains where it belongs—in the layers behind the interface. 
 

This research was made possible by the opportunity to investigate the above-described challenges as part of Task 2 – Development of new methods for geovisualization of user data on the RFBenchmark portal – frontend, carried out under project No. FEMA.01.01-IP.01-02E5/24-00, “Optimization and Enhancement of the Platform for Analyzing and Assessing Service Quality in New Generation 5G Mobile Networks.” 

The prototypes and solutions developed within Task 2 do not constitute a complete, standalone commercial product fit for immediate use, nor a fixed asset within the meaning of Article 3(1)(15) of the Polish Accounting Act. They remain at the conceptual and experimental stage and require further optimization, scaling to the full volume of real-world data, validation under production conditions involving very high traffic loads, and integration with the remaining modules of the platform — activities that fall outside the scope of this research and development project.