Background
OpenStreetMap (OSM) relies on a wide variety of contributions in terms of mapped themes, areas covered, and levels of completeness. This flexibility is the key to its richness and success. However, it also results in a high degree of data heterogeneity, a point often cited by its critics or those who seek to downplay its value. OSM combines areas that are extremely detailed, sometimes even down to multiple floors of a single building, with others where essential information is completely missing.
This heterogeneity applies equally to data extracted from aerial imagery and to data collected on the ground. Thus, the mere presence of a categorized settlement or the road connecting it to the rest of the road network is still missing in many areas, particularly in the Global South, where the number of OSM contributors is smaller.
Northern Senegal, with mapped localities (named nodes and residential areas) that are not connected to the road network – Click to open the interactive map on OpenStreetMap.
Western Bahia State, Brazil, including localities connected to the road network but excluding their residential areas, whose urban extent is therefore unknown – Click to open the interactive map on OpenStreetMap.
Similarly, some small towns have a significant number of points of interest (POIs), while others have none at all. There are many situations in between, both in terms of the total number of POIs and the categories represented.
Projects for validating OSM data already exist (Osmose, MapRoulette, OSMCha…), but none of them truly addresses or focuses on resolving these issues of heterogeneity. This does not prevent OSM from being a valuable resource – even an indispensable one – where there is no alternative for detailed, freely accessible data that can also be updated. There are numerous well-known examples in the fields of development and humanitarian aid. But this heterogeneity of the OSM map limits its potential: for example, while it could serve as the reference dataset in many regions, it struggles to fulfill this role when compared to regional or national datasets that are inherently less detailed, less – or not at all – updatable, and often more difficult to access, but which are more consolidated.
This is what the OSM Skeleton conceptual, methodological, and technical approach aims to address: to drastically reduce the heterogeneity of OSM data by identifying issues in a systematic and prioritized manner, starting with the most fundamental features across large areas – typically at the national level – before moving on to more local scales and secondary features.
The ambition of this methodology is to create a clear “before and after” in the areas where it is applied, transforming OSM data from a patchwork of uneven mapping contributions into a geographic reference dataset that is freely accessible and editable. This new consistency can be maintained in the long term if active communities, national institutions, or international organizations decide to take this methodology on.
The OSM Skeleton Approach
It works as follows:
-
Prioritization of fundamental objects. OSM Skeleton focuses first focuses on objects that are considered the main framework of OSM data. These objects, which are presented in the next section, are considered as fundamental both because of their intrinsic characteristics – which form the basis of any geographic reference data – and because they facilitate the analysis of the heterogeneity of other objects.
-
Identifying issues. OSM Skeleton identifies all missing, inaccurate, incomplete, or obsolete objects within the OSM data framework to address their heterogeneity. By default, this detection is performed at the national level, as the project aims to establish geographic reference data.
-
Contextualized resolution. Each problem – whether confirmed or potential – is represented by a specific layer and can be resolved by clicking to access the corresponding area in an OSM editor, where users can modify the existing OSM data using detailed instructions and freely available imagery for OSM contributions.
-
Flexible prioritization. The most critical issues are highlighted, but others considered more secondary are also suggested, as they complement the former and will also help address the heterogeneity of the data set.
-
Flexible organization of activities. This flexibility allows mapping work to be organized using two complementary approaches: addressing issues sequentially across the entire territory, or proceeding zone by zone, moving on to the next zone once local issues have been resolved.
-
Anticipating the steps to be taken. Issues of heterogeneity that require field mapping to resolve can be identified from the outset, even if their precise assessment will only be possible after addressing the issues using imagery.
The backbone of OSM objects
At the heart of the OSM Skeleton approach, certain objects are considered fundamental because they form the backbone for characterizing human settlement in a given area. Each of these fundamental objects is represented by one of the three primitives of vector data: point, line, and polygon.
First are the nodes which characterize settlements based on a category (such as place=city/town/village/hamlet) and a name, when known. They can be considered a kind of reference point for all other data layers.
Secondly, the road network is essential for connecting settlements and forms the basis for all accessibility and navigation calculations.
One might imagine that these two types of fundamental objects – which make up the primary network covering a given area – would already be fully represented in OSM, more than twenty years after the project’s inception, but that is not yet the case. The example below shows all highway and place objects in northwestern Senegal. We can see that they are well-connected in some areas, while in others there are isolated points or, conversely, lines that are disconnected from the rest of the network and do not intersect with any other points.
Finally, the residential area – sometimes overlooked by certain OSM mappers or in map renderings – is nevertheless a fundamental feature when working on a greater scale, that of individual settlement areas, both to characterize and analyze them. Through its shape and area, it allows us both to verify the category provided by the place node and to specify the extent of the settlement area. As a polygonal feature, the residential area is also used to analyze everything it should contain or intersect: settlement nodes and the road network, as well as streets, points of interest (POIs), or buildings.
If OSM mapping were to follow a step-by-step process, it would only make sense to delve into the internal details of the locality – such as mapping its road network – after these three fundamental objects have been created, as illustrated in the diagram below.
Urban areas: a hybrid feature for analysis
Since residential areas in OSM are sometimes incomplete, lacking in detail, outdated, or even missing, OSM Skeleton uses a hybrid feature called “urban areas”, which combine each OSM residential area with the polygon encompassing the street network mapped in OSM, along with various metrics: respective areas, number of intersected residential areas, number of localities by category, aspect ratio, number of intersected highway objects (streets and other types of roads), and date of last update. These indicators will help identify various types of issues in the OSM data intersecting the residential area.
In the future, the analysis should also include rural areas where residential zones are not traversed by streets, but by trails, simple paths, or even have no detectable routes visible in satellite imagery.
Skeleton layers
Each type of problem – whether confirmed or potential – is represented by a specific layer containing point-based reports. The most critical layers are typically those concerning fundamental objects that are still missing. Addressing these layers is therefore a prerequisite for subsequent steps aimed at correcting errors or improving accuracy. These most critical layers are as follows:
-
Place node without a residential area
-
Missing place node
-
Place or residential area not connected to the main road network
-
Urban area without a residential area or place node
-
Settlement area not yet mapped in OSM, compared to a global reference dataset. This layer is the only one that uses a reference dataset external to OSM, provided by Copernicus GHS.
Secondary layers intended to supplement the analysis are designed to correct errors and inaccuracies affecting existing fundamental OSM features. Errors primarily concern the categories of settlements and traffic routes. Inaccuracies relate to the geometry of residential areas, which reduces their analytical value if they do not accurately reflect reality.
The current, non-exhaustive list of these secondary layers is as follows:
-
A locality node categorized as a small town but whose area appears too small
-
A locality node categorized as a village but whose area appears too large
-
A locality node categorized as a village but whose area appears too small
-
A locality node categorized as a hamlet but whose area appears too large
-
Obsolete residential area
-
Residential area with rough accuracy
-
Residential area where streets appear to be missing
-
Residential area that appears too small relative to the street network
-
Isolated streets, outside any locality
Some layers can identify several different issues. For example, “Urban areas without residential zones or place nodes” can correspond to either missing objects or the incorrect use of the tag used to mark streets in OSM (highway=residential).
The following image shows the first six layers implemented across Senegal; the others will be available in the coming weeks:
Since there are often a large number of identified issues at the national level, layer display rules are set to show only the most significant reports at the smallest scales. Some styles are nestable, allowing for the overlay of multiple types of issues, such as residential areas with rough accuracy or outdated.
These layers were tested in Senegal and the state of Bahia, Brazil, which feature both contrasting geographic contexts and significant differences in their heterogeneity.
To address the heterogeneity of data that can only be mapped in the field, OSM Skeleton already provides a score from 0 to 10 for cities and towns, reflecting the density of key POI categories relative to the area of the populated zone: healthcare, education, other facilities, retail, and offices. Detailed POI counts are provided for each of these categories. This layer highlights disparities among towns and, in particular, helps identify those with the least detailed data. Beyond its analytical value, it can serve as a useful tool for planning field mapping activities.
OSM Skeleton Technical Environment and Workflow
From a technical standpoint, OSM Skeleton – unlike many tools in the OSM ecosystem – does not rely on a web architecture with dedicated back-end and front-end components. OSM Skeleton is hosted within a geOrchestra Spatial Data Infrastructure (SDI) and deployed as OGC layers, which are updated daily. Users can access these layers directly from geOrchestra’s MapStore mapping interface or any OGC client, such as QGIS, in the form of downloadable vector files or WMS/WFS layers.
The current demo for Senegal is accessible:
-
via the URL https://ifl2.francophonelibre.org/geoserver/OSM_SN_skeleton/ows? to add WMS access in OGC clients
When a report is clicked using the query tool, a panel appears with information and a clickable link, as shown below in MapStore and QGIS:
To avoid duplicating edits, the web page notifies the user when the report has already been opened recently in an editor.
To avoid duplicating edits, the web page notifies the user when the report has already been opened recently in an editor.
When you click the link, a web page provides instructions, displays the date the layer was last updated, and lets you choose the editor in which to open the area to be mapped.
It is possible to provide country-specific instructions and even instructions for specific contexts within a country. False positive handling will also be added soon.
The scripts, internal API, instructions, and layer styles are hosted on Codeberg at this address: https://codeberg.org/leslibresgeographes/osm_skeleton. The code is licensed under GPL-3.0 or later, and the instructions are licensed under CC-BY-SA, with the specific version depending on the source.
Monitoring Statistics
An initial statistical dashboard has been designed that shows, for each layer, the number of alerts by category and how that number has changed between the date the database was created (in April 2026) and the present day. It allows users to visualize both the volume of alerts that need to be addressed and the progress made in mapping them out to resolve them. As of early July 2026, there are few differences in Senegal, as only a few alerts were processed during testing. It is worth noting that the number of alerts is sometimes even higher in July than in April, indicating that new problems have arisen in the meantime.
OSM Skeleton is a project that has been carried out through volunteer work thus far and has been supported by Les Libres Géographes’ technical resources. In early June 2026, a funding request was submitted to NLnet Foundation with the aim of continuing the creation of layers, styles, and instructions, adding features to the internal API, and developing statistics. A testing phase was also proposed for a few additional regions. NLnet’s response is expected in the fourth quarter of 2026, but in the meantime, the project is open to receiving other funding proposals.
Implementing Skeleton Mapping
Since the code is freely accessible and usable, anyone can implement OSM Skeleton in their own way: across a country or just a region; working alone on a local machine; or as part of a large team within an organization.
Beyond the initial creation of the methodology and the code, Les Libres Géographes also aims to participate in the implementation of this mapping initiative, which seeks to reduce the heterogeneity of OSM data in order to build national-scale geographic reference data, particularly in the Global South. Rather than the traditional approach of having mappers work across all target areas – whether they are volunteer contributors from the OSM crowd community or a paid international team – LLg promotes the following approach:
-
Engage the best local OSM mappers from each country being mapped, who will have a deep understanding of the specific local context
-
Pay these mappers, which is justified given that the resulting leap in quality will make the OSM data even more valuable to various stakeholders who will be able to benefit from it
-
Organize simultaneously in-person workshops to raise awareness of this standardized OSM data, led by the same mappers – who are active in their OSM communities – for all interested local stakeholders
-
Incorporate a community-building component by providing each local OSM community with the resources to organize activities of their choice, as LLg has always sought to do in all its field projects
-
Prepare for the field mapping phase of POIs by encouraging the emergence of local mappers in both small and large cities
Translated with DeepL.com (free version)
