SpatiaLite Databases for Community Mapping

3 minutes read

All Geospatial projects contain an element of data collection and preparation. This is vital stage in project execution that has to be dealt with carefully and correctly as it would lead to loss of time and resources. Participatory mapping involves set of techniques and approaches that combine the tools of modern cartography with participatory methods to represent the spatial knowledge of communities or groups. The projects involve large numbers of data collectors and digitizers. Often, the data dealt with cover wider geographical areas and usually take time to complete the tasks. In cases of decentralized working setup, numerous errors are caused between groups leading to the need to allocate more resources and time to fix these errors.

The need for more resources lead to stalling of the project or/and ending the project completely. Many participatory mapping projects end up this way. This might lead to chaos as blame-game will shift to project managers or users for funds embezzlement. I won’t dwell much on this as it’s a story for another day. Due to such issues, better and smarter solutions have been developed for use freely and openly. Different work-flow and tools are used in different projects depending on a number of factors.

In this article, I focus on spatial data manipulation, cleaning and storage. In a real-world project scenario, on community projects, the community members are trained on various techniques and tools so as to empower them to carry out the project within their areas or locality. As always attested to, the community’s members know their locality better. With this in mind, for example, the groups or teams are trained on data collection methods, data cleaning and preparation and finally the map making techniques. With such an approach, there is ensured continuity of the project and motivation among the participants to map their resources or areas even better.

This therefore, brings in the need to manage data collected by the members, keep record of the different versions of data and final outputs from the work. This process is continuous leading to the need of a versatile and robust system of working that will ensure the project objectives are achieved. Below is an illustration of a working environment, of which represent most working groups and agencies involved in community mapping.

Working Setup(Various users and Database)

The diagram above illustrates a working environment where the project team (Digitizers, manager, supervisors, donor etc) can share a database and access different type of data depending on their levels and requirements. Most of the community mapping projects work on and produce freely accessible data to all the stakeholders involved in the project. In this case, the proposal for SpatiaLite database doesn’t consider data security as one of the key factors at work. Connection to the database can either be Wi-Fi or LAN depending on the size of the dataset being accessed. Of course users have preferences at work.

Why SpatiaLite?

  • Support by most, if not all, software that exist in Geospatial (Interoperable)
  • It’s OGC compliant.
  • The whole database is simply a file enabling sharing, transferability and no configuration required.
  • It’s versatile, allowing large numbers of community users to connect at a go.

Data Quality

Participatory/community mapping involve quite a big number of digitizers and players. Data acquired from different teams differ in different aspects such as accuracy, correctness and completeness. These factors determine the quality of the data which is a huge concern in these projects. To ensure data quality, supervisors can review all data worked on by the digitizers (As a way of marking the work) and flag the errors that may exist in the dataset.

How is it done?

  1. The supervisor accesses the same layer worked on by a digitizer from the database, checks it through, highlighting the errors in the data (templates and forms are customized for this in the layer in e.g. QGIS). The errors can have different flags depending on type of error
  2. The digitizer is notified of the corrections, accesses the same layer, finds all the errors and corrects them
  3. The supervisor is notified of the digitizer’s corrections and counter-checks the changes. If all the corrections were made correctly, the layer is flagged as good or complete or finalized. Choose your words. If not all correct, the supervisor marks the errors again for the digitizer to correct.
  4. This process is continuous until an ideal version or quality of the data is achieved. SpatiaLite has proven to be a key tool in community mapping and continues to introduce more functionality to enhance interaction with spatial data and other work-flows.

For more details, watch the SpatiaLite Tutorial

What’s your experience with SpatiaLite? Share in the comments section.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.