New Tool Audits OpenStreetMap Data for Scientific Research

The tool addresses a specific challenge in geographic information science: the variability in how similar real-world objects are tagged and structured within the OSM platform. By providing a workflow that records the exact source data, the classification rules applied, and the resulting export transformations, the software aims to support scientific studies that rely on volunteered geographic information for transport, infrastructure, and environmental research.

The core motivation for the software stems from the inherent inconsistency in OSM data representation. Objects that serve similar analytical purposes, such as different types of power infrastructure or road segments, may use different keys, values, and lifecycle conventions. This variability complicates the creation of reproducible datasets for scientific analysis. The converter distinguishes between the uncertainty of the mapped information itself and the reproducibility of the data transformation process. While the software cannot verify whether mapped features exist on the ground, it ensures that the process of selecting and exporting those features is transparent and inspectable.

The software architecture supports two distinct processing modes: a full-project mode and a targeted-road mode. The full-project mode is intended for studies that require a comprehensive inventory of the tag vocabulary within a specific OSM snapshot. It reconstructs the data using five logical layers provided by the GDAL OSM driver: points, lines, multilinestrings, multipolygons, and other relations. This mode aggregates per-feature tags in a SQLite database to avoid excessive memory usage, a design choice driven by an early prototype failure where in-memory sorting consumed approximately 13 GiB of RAM. The targeted-road mode, introduced in version 0.4.2, offers a faster path for predefined highway selections, bypassing the complete vocabulary inventory and associated quality checks.

Semantic selection in the converter is performed through versioned JSON profiles that define analytical categories and Boolean rule expressions. These profiles allow researchers to explicitly define how tags are interpreted, including lifecycle states and object-type constraints. For example, the targeted highway profile permits 13 specific values grouped into four analytical categories, restricting all rules to the GDAL ‘lines’ layer. This approach ensures that classification decisions are explicit and reviewable, rather than hidden within opaque code. The software also records the hashes of the input files and profiles, linking the output data to the exact source snapshot and configuration used.

The empirical evaluation of the full-project mode involved four regional datasets of varying sizes: Berlin, South Korea, New York, and Quebec. The Berlin power-infrastructure example, based on a 94.2 MiB snapshot, yielded 2,525,682 reconstructed tagged features and 11,709,632 tag assignments. The power profile matched 6,726 objects, including generators, substations, and cables. In the national-scale South Korea extract, a 271.3 MiB file produced 4,587,351 reconstructed features, with the aeroway profile matching 9,304 objects. The New York case, using a 471.4 MiB PBF file, generated 11,434,477 reconstructed features and 6,576,398 unique key/value combinations, identifying 3,078 pipeline-related objects.

The largest test case was the Quebec dataset, a 1.08 GiB input that produced 12,382,811 reconstructed objects and 475,166 matched power features. The processing times for these full-project runs varied significantly based on the size and complexity of the data. Wall times for Berlin, South Korea, New York, and Quebec were approximately 4.1, 8.5, 51.4, and 29.7 minutes, respectively. Sampled peak process-tree resident memory ranged from 481.1 to 633.1 MiB across these runs. These measurements describe the tested regional-to-national cases and do not establish constant-memory complexity or planet-scale capacity, as workload and storage behavior affect elapsed time.

A separate fixed-input experiment evaluated the targeted highway mode using a Brazil Sudeste snapshot. The study compared a minimal direct-GDAL/Python extraction with the targeted converter extraction on the same workstation. The direct-GDAL operation took 89.179 seconds, while the targeted converter extraction took 126.289 seconds. Both methods selected 2,067,117 objects with identical canonical-ID multisets. The converter’s output included category assignments and limited provenance records, which the direct-GDAL baseline did not provide. Because the operations differed in their processing obligations and were run only once each, these timings do not establish performance equivalence or isolate algorithmic overhead.

The software also addresses the reproducibility of export formats. GeoPackage is the principal archival container, retaining complete tag information without detected truncation in the tested Berlin export. In contrast, Shapefile outputs are subject to legacy DBF field-name and width constraints, which the software records as observed truncations rather than treating them as format defects. GeoJSON is supported for text-oriented interchange, while GeoParquet is not yet implemented but is identified as a potential future format for columnar analytics. The export audit helps users distinguish between representational limitations of a format and semantic selection decisions made during the extraction process.

Limitations of the software include the fact that deterministic samples and rule records concern process consistency, not real-world completeness or positional accuracy. The built-in previews are bounded and do not substitute for topology inspection or external spatial reference data. The Brazil highway experiment was limited to one run per approach, preventing the establishment of benchmark variability. Furthermore, source-layer restrictions define the exported subset but do not demonstrate that the underlying GDAL parser skips all irrelevant bytes while parsing the PBF file. These limitations define the scope of the present evidence and inform subsequent software evaluation.

The OSM Scientific Converter provides a documented input dataset for downstream scientific analyses, such as exposure, proximity, and hazard modelling. It does not perform these analyses itself but ensures that the data preparation is transparent and reproducible. By associating decisions with hashes and process records, the software supports inspectable data preparation and selected FAIR stewardship principles. The tool is particularly relevant to heterogeneous infrastructure themes whose interpretation may change as tagging conventions evolve, offering a way to recover how a thematic feature set was selected and transformed.

The development of this tool reflects a broader trend in GIScience toward recoverable inputs and transparent processing. This approach allows researchers to revisit observed tag distributions and classification decisions, enhancing the reliability of studies based on volunteered geographic information.

Future versions of the software may include support for additional export formats and more extensive benchmarking under controlled conditions. The current version, v0.4.2, is available as a Windows x64 standalone release, with the source code licensed under the MIT License. The software requires Python 3.12 or higher and uses GDAL/OGR for data reconstruction. By providing a clear and auditable workflow, OSM Scientific Converter aims to bridge the gap between raw OSM data and the rigorous standards required for scientific research, ensuring that the data used in studies is both reproducible and well-documented.

Subject of Research: OSM Scientific Converter: an auditable desktop workflow for input-driven discovery and thematic extraction of OpenStreetMap data

Article Title: OSM Scientific Converter: an auditable desktop workflow for input-driven discovery and thematic extraction of OpenStreetMap data

Article References: Du, Q., Li, G., Wang, F., Ma, W., & Mu, Y. (2026). OSM Scientific Converter: an auditable desktop workflow for input-driven discovery and thematic extraction of OpenStreetMap data. SoftwareX, 36, Article 103200. https://doi.org/10.1016/j.softx.2026.103200

Image Credits: AI Generated

DOI: 10.1016/j.softx.2026.103200

Keywords: Scientific, Converter, auditable, desktop, workflow, input-driven, discovery, thematic, extraction, OpenStreetMap, data, scientific research