The goal is simple to describe, but powerful in practice: create maps that show where people live and what matters to them. Rivers and mountains, hunting grounds, important forest resources, and the borders people recognize as their lands. The maps are built with the community, in their language where possible, and based on their understanding of the landscape.

This is not only useful for planning and storytelling. In at least one case, a community map was used in court as evidence of long-standing connection and use. The community could show place names and key sites in a way that helped to prove that they have been living in those areas for a long time.

Why mapping needs more than satellite imagery

Satellite imagery and topographic maps are helpful starting points. They show rivers, ridges, clearings, and settlement patterns. But they do not capture meaning.

A satellite image can’t tell you where ancestors are buried, where a place is considered sacred, which part of the forest is used for hunting, or which areas people avoid for cultural reasons. Those details live in stories, memory, and daily practice.

The reality in the field: connectivity comes and goes

A second challenge is technical but very real: internet access. Many of these villages have unreliable connectivity, and “offline” can mean days or weeks, not just a few hours between the office and the field.

That matters because community mapping usually involves large basemaps and plenty of edits from multiple devices. If you can’t reliably push data back and forth online, you need a workflow that works without it.

How QField is used in the workflow

The team prepares a QGIS project and packages it for mobile fieldwork using QFieldSync. Then QField is used for collecting features and attributes directly on Android devices in the field. A key part of this project is that distribution and syncing often happens by cable, not through the cloud.

1. Co-designing the project with each community

Before fieldwork begins, the team sits with the community and adapts the project to what they want to map.

Different communities care about different things. A village close to a river may want specific river sections and names recorded in detail. Another community might focus more on forest resources or cultural sites. Together, they decide:

• What feature types to include
• How features should be represented (point, line, polygon)
• Which attributes matter (names, local terms, notes, photos)
• What should be captured in the local language

This step is not only about data structure. It is about decision-making. Many communities have had mapping done to them by outsiders. Here, the community defines what the place is called, what counts as important, and what should be left private.

2. Moving projects and data without the internet

Because basemaps are large and connectivity is weak, the team transfers projects to devices using a cable. Community members collect data in the field and return to a local computer where the data is brought back into the QGIS project.

Later, when a stable connection is available, the consolidated dataset can be pushed to a database or cloud service for wider viewing and backup. But the core mapping work does not depend on that connection.

This also changes how versioning is handled. In the “industrial” workflow, you often assume you can sync frequently, resolve conflicts quickly, and keep changes small. In this context, the gaps are longer and the differences between versions can be bigger. The team keeps multiple versions and, when needed, compares and fixes conflicts manually to protect data quality.

A moment of real impact: giving the map ack immediately

One of the strongest moments in the interview was what happened when the community saw the collected data on their own phones. At first, the idea might sound like giving people a basemap. But it was more than that. It was their own collected layers, their own names, their own places, and their own priorities, visible immediately. It became a local “Google Maps,” except it reflected their world rather than someone else’s.

That created interest fast. The mapper described an evening when many community members showed up with smartphones, asking to get the map on their devices. For the project team, that was a clear sign the mapping wasn’t just a report deliverable. It was something people wanted to use and keep. QField made it possible for every community member to carry community data in their own pocket. So far, QField has been used in two communities, and its success ensures that it will be used again.

Being careful about what is share

The project is also very deliberate about data protection. Not everything that is mapped should be published. Sensitive cultural sites, graveyards, and other locations can be exploited if they are made public. Even among neighboring communities, boundaries can be contested, and publishing one version can create conflict.

For that reason, the team does not plan to publish all data to the web or to OpenStreetMap. There is interest in selectively sharing non-sensitive layers, such as river names, but only with consent and clear boundaries.

The final deliverable that matters most: a printed map

Digital maps are essential for fieldwork, but the “finished” outcome for many communities is a high-quality printed map, with a thoughtful layout and space for metadata and stories.

A printed map does something phones do not. People can spread it out, gather around it, point to places, and talk. It feels permanent. It can be stored, shared, and used as proof in a way that carries weight locally.

For the BMF and the Communities, the printed map is not an afterthought. It is one of the main goals, alongside the longer-term aim of keeping community data organized in a comparable way across multiple mapping projects.

To conduct data collection of all rural water supply network in Rwanda, and keep updating the data continuously in order to improve operation & maintenance of waterworks.

Project preparation

Before starting our data collection, we conducted the following things: – Develop our own PostGIS database – Develop QGIS project template with Geopackage. The Geopackage table design is equal to PostGIS to be able to copy and paste to PostGIS.

Apart from preparing Android devices, we purchased GPS devices for higher positioning accuracy. In WASAC, we bought Garmin GPSMAP 64S. Sometimes, GPS of smartphone and tablet is not very accurate, so we normally capture the same location by using Garmin GPS, then correct the location of QField’s data after data collection work.

Data collection

Once we prepared Geopackage and QGIS project template, we conducted training of QGIS/QField in July 2018 and launched our data collection work in 27 districts in the whole country of Rwanda. 27 engineers sent their Geopackage to the central office in Kigali. the MIS (Management Information System) specialist validated and entered their data from Geopackage to PostGIS database. We completed our initial data collection works until April 2019.

Data collection procedure

Data distribution and updating

The most significant thing after data collection is updating. We have seen many organization in Africa, which failed to keep data up to date. Several years later, their data will normally become too old, and most of them need to put efforts on data collection again. WASAC decided to continuously update all of the data and keeps doing this until now. QField has proven to be very well suited for this purpose. In order to distribute and updating the data, we developed a python script postgis2qfield. This postgis2qfield tool can extract the data from PostGIS and create Geopackages for each district in Rwanda. We upload these 27 geopackage together with QGIS project template to Google Drive storage. After that, those engineers in districts download their geopakage to Android device to continue adding and updating the data. Once they completed updating, they sent the geopackage to central office again, MIS specialist update PostGIS database and regenerate geopackages for QField.

Data distribution and updating procedure

Data sharing via vectoriles

First of all, you can see our collected data from here .

Since July 2020, we started to distribute our water supply system’s data via vectortiles as open data. Although Rwanda's internet situation is being improved, some rural area still have problems of internet. In such as poor internet situation, WMS or WFS data distribution will not work well. Vectortiles can provide light and fast distribution of map data. We will not talk about our vectortiles here. If you are fascinated by how to share the result of data collection, please also see this instruction .

Acknowledgement

We thank all of district water and sanitation support engineers to conduct their data collection work. Additionally, we want to thank the developers of QField and QGIS for offering fantastic open source software. It is great that, due to free software, such projects can be implemented by an organization of water sector in developing countries.

About WASAC

WASAC has 2 main departments for urban water(UWSS) and rural water(RWSS). We are using QField in RWSS. The role of RWSS department is to support local government to operate and maintain their owned water supply systems in rural area. Nowadays, these data collected and maintained by RWSS department are being used by more than 30 private operators in 27 districts. Total number of water supply systems in the database is 1,000+.

Organogram of WASAC

Also, one of our colleagues presented WASAC's activity in FOSS4G 2019 Bucharest. Although some of system were little bit changed now, you can also see this video if you are interested.

Developed over several years and officially rolled out in spring 2025, MTTJ gradually replaces legacy proprietary systems with a modern, efficient, and extensible solution tailored to NLS’s evolving needs — all while promoting transparency, interoperability, and long-term sustainability. As part of this open architecture, QField will play a key role , empowering field teams to collect and validate data efficiently, even in remote locations. Use of QField is being piloted over summer 2025 and will be gradually taken up for full production use towards the autumn.

“QField lets our field staff work smarter and faster, even in the most remote corners of Finland. It’s a vital part of our open-source geospatial infrastructure.” — Jani Kylmäaho, Director of Development and Digitalization, National Land Survey of Finland

Throughout the development of MTTJ, the National Land Survey of Finland actively engaged with the QField project, contributing not only feedback and use cases, but also procuring for the development of new functionalities key to NLS use cases to QField core. This close collaboration ensured that QField evolved to meet the demanding requirements of national-scale field data workflows and continues to benefit the wider open-source geospatial community.

Built for Performance, Collaboration, and Openness

The new system supports 100–150 concurrent operators, integrates photogrammetry tools, and offers robust real-time quality assurance and job management features. The architecture is centered on QGIS, PostgreSQL/PostGIS , and a custom set of plugins and APIs designed to streamline workflows from aerial imagery to finished topographic data

Among its standout features:

• Task and conflict management tools directly within QGIS
• Workspace-based editing to prevent data collisions
• Tight integration with QField for field data collection

All core components were built with open-source principles in mind — and many will be shared with the global QGIS and OSGeo community.

Seamless Field-to-Database Workflow

Finland’s mapping authority integrated QField and QFieldCloud to allow field staff and aerial image interpreters to:

• Collect and verify topographic features onsite,
• Access up-to-date maps and imagery offline,
• Digitize observations with domain-specific presets,
• Sync edits back to central databases using open standards.

This QField-enhanced workflow helps ensure high positional accuracy, real-time feedback, and consistent data quality , even when operators are far from headquarters.

Designed for Professionals, Chosen by a Nation

The NLS chose QField not only for its powerful offline capabilities and QGIS compatibility, but also because:

• It offers an intuitive user interface,
• It offers powerful functionalities,
• It enables field validation workflows,
• It’s adaptable, multilingual, and field-tested.

By integrating QField into a national strategy, Finland has showcased how modern, mobile-first open-source tools can outperform legacy systems — all while reducing costs and increasing flexibility.

Learn More

• Official NLS announcement
• Article in Positio Magazine
• FOSS4G Europe 2024 talk by NLS
• FOSS4G Europe 202 talk by NLS

To collect new data on bedrock geology and view existing geoscience data in the field. Geologic mapping is completed using paper maps and/or digital devices for data collection. The goal is to improve the geologic mapping workflow by entering data directly in the field, create quality data with consistent terms, and reference existing geoscience data in the field.

Project preparation

Prior to starting in QField, a geologic mapping geopackage was designed to collect vector data including point station, structure, photo, and sample layers as well as line and polygon layers for contacts, faults, alteration, and geology. Attribute fields are customized for ease of data entry and data quality assurance using value maps, defaults (value or expression), and constraints within the Attributes Form. For example, the structural layer includes:

Coordinates

Fields with default value x and y coordinates from GPS data

Structure type

Value map (drop down list) with structural features (e.g., bedding, cleavage, lineation), set with a “not null” constraint

Azimuth and dip

Integers with range set from 0-360 and 0-90, respectively

Date

Default value current date and time when feature created

Figure 1: Structure list

Symbology and labels are customized for each layer, including embedded SVG symbols for structural features that are rotated with the azimuth field. In addition to field data, base maps and historic data are compiled into geopackages for reference. Base maps include vector topographic data and raster orthophotos. Raster geophysical data and vector geochemical data are included if available, as well as historic geologic mapping. Map themes are designed to quickly toggle between geologic mapping, geophysics, and geochemistry views.

Data collection

Field data collection includes adding point data for map stations, structures, photos, and samples. Polygons and lines are drawn freehand with a stylus or adding vertices manually.

Location and direction of travel are displayed using internal device GPS (or external GPS device linked via Bluetooth), historic vector and raster layers can be viewed relative to location. Current and historic vector layers can be searched and viewed in QField.

Field data are synchronized in QGIS followed by a short data clean up and verification process. The QGIS project is then exported back to QField for additional data collection.

Figure 2: Field work

Figure 3: QField form

Structural data collection may be upgraded with future development of a geologic compass feature. https://github.com/opengisch/QField/issues/1882

Results

Final geologic maps and analysis are prepared directly from field data sets with no need to digitize field data. Depending on proficiency and type of mapping, the QField geologic mapping workflow takes approximately the same amount of field time as manual (paper) mapping and drastically reduces office data digitization time. Additionally, historic data are easily referred to in the field, allowing for real time interpretation and targeted field work. Maps and attribute tables can be exported directly from QField or the QGIS project for daily field updates or communication between working groups. QField allows for data integrity with customizable attribute fields and database compatibility. Field data quality assurance can be built in during project design, ensuring attributes are consistent between users and reducing human error with constraints and default values.

Figure 4: Map result

In order to assess the structural and morphological state of their water courses, the community of Milvignes needed to survey all the rivers crossing their territory.

Project

To facilitate the technician’s field work (usually done with a map, a notebook and a camera), a QField project was created and made available on a Tablet. Cadastral and river layers were used as basemap.

The structure of the input tables was designed along with the technician to assure that it would fit their field requirements. The idea was to have two tables:

Sector table

To draw sectors alongside the rivers and add information about their state and structure. If necessary, pre-defined structural work on the sector elements (wall, bridge, bottom of the canal) could also be documented.

Point table

To take punctual photography of the water courses and of its elements and where necessary add remarks.

River State Survey 1

River State Survey 2

River State Survey 3

Result

In less than 3 days, the technician surveyed successfully all the 10'894 meters of water courses. Back at the office, it took only 2 hours to treat the data and get the final result:

– Facilitated the field survey – Accelerated the data treatment