Thanks for sharing your workflow, but I have some concerns about both the tagging approach and the broader editing pattern here.

The description=* tag is intended for a neutral, factual statement of what a feature is — not a list of services. Content like “driveways, patios, foundations, repair, commercial” is marketing copy rather than geographic description, and isn’t really what downstream data consumers such as Nominatim are designed to surface. The correct place to capture services is service:= tags where applicable, or simply leaving description=* absent.

More broadly, eight nodes with identical description values, all tied to a single commercial brand relation and a business website, looks more like SEO-motivated data entry than survey-based mapping. OSM’s verifiability policy asks that every tag reflect something that can be checked on the ground — a keyword list copied uniformly across multiple cities doesn’t meet that bar.

If these offices genuinely exist and have been visited or verified, the right approach is accurate address, phone, and opening_hours tags on each node, with name=* reflecting the signage as it appears. For a contractor’s office, office=company or office=construction would be the appropriate primary tag — see osm.wiki/Tag:office%3Dcompany and osm.wiki/Tag:company%3Dconstruction for guidance. The US-specific tagging guidelines at osm.wiki/United_States/Tags are also worth a read for general conventions.

The brand relation is fine if it groups real locations, but the description tags as added don’t add geographic value and risk being removed as promotional content.

I’d suggest revisiting those nodes and aligning them with the OSM wiki guidance on verifiability. Happy to help think through the right tagging if useful.

Roger, roger!

Thanks for sharing, that’s a nice coincidence! A bat hibernation survey and a pillbox/bunker inventory overlap perfectly in terms of the physical locations, so the same MapComplete layer could serve both use cases if it were ever developed further.

No pressure to take it any further than a quick draft; it’s useful to know MapComplete can handle historic=bunker nodes at all. I’ll keep the proposal moving forward through the wiki process.

Cheers,

Chris

Progress update — June 2026

It’s been six months since the original post, so a brief update on where this has got to.

On the UKBOTA side, the gap analysis is substantially complete. UKBOTA (https://ukbota.net) is an amateur radio award scheme for activating historical bunkers — think Summits on the Air but for bunkers. Cross-referencing the eDoB extract (10,682 extant sites) against the UKBOTA master list identified over 9,000 candidate sites not yet on the UKBOTA reference list. Of these, 38 had matches in the Historic England National Heritage List, and 10 candidates had strong enough documentary evidence (HE listing + Defence of Britain record) to submit formally. 8 were accepted and are now in the June 2026 UKBOTA list, with 2 further submissions pending review — a good proof of concept for the data-driven approach.

The tagging research has moved on considerably since December. Working from four sources — UKBOTA’s own type vocabulary, eDoB terminology, Historic England monument type names, and UK taginfo — I’ve put together a cross-community matrix covering the main structure types. A few things stand out: bunker_type=pillbox is well-established (1,907 uses in the UK), but there’s no agreed sub-tag for pillbox design types, despite the FW3 classification system providing a solid, well-documented basis for one. ROC posts are entirely absent from OSM bunker_type tagging despite 1,609 entries in UKBOTA. And bunker_type=observation and bunker_type=observation_post are both in use (64 and 10 respectively) with neither documented.

Following SimonPoole’s advice from the comments, the tagging proposal will be taken to the UK OSM community forum rather than developed further here. I’ll be posting there shortly with the matrix and a proposed approach, starting narrow (rationalising the observation post tag split) before moving to larger proposals. Feedback from the Pillbox Study Group will be sought before anything goes to a vote. Pieter’s MapComplete bunker theme is already ahead of where the wiki is — filling those empty stubs will be part of the follow-up work once there’s forum consensus.

@Pieter: That’s fantastic; thank you for building this so quickly! I’ve had a look at the theme and it’s exactly the kind of verification tool I had in mind. I notice it uses historic=bunker as one of the primary tags; I’ve been researching the OSM wiki and that tag page is currently an empty stub. Part of the work I’m planning before the UK forum post is drafting content for that page, so the two efforts align well. I’ll make sure the wiki page content complements the MapComplete theme. Really useful to see it in action.

Chris

Looking good, Pieter!

Chris

@Fizzie-DWG:

Thanks — good suggestion, and taken on board. The OSM Forum is definitely the right place to take this further if I pick it up again.

@SK53:

Apologies for the very late reply. Thank you for the pointers — the Bright and De Sabbata paper sounds exactly the kind of rigorous grounding this kind of work needs. DisasterNinja’s coloured hexagon approach is interesting; a visual, map-based quality indicator is much more immediately useful than a raw league table. I’ll look at both when I return to this topic.

@Richard:

Apologies for the very late reply. Path Surveyor sounds like exactly the kind of thing I had in mind — good to know the iOS space had something. MOROW has since been built as a Flutter app, which means Android-first but with iOS extensible from the same codebase, so in principle an iOS contributor could add support without a rewrite. The app is now open source at codeberg.org/morow/morow if you’re interested.

@MxxCon:

That’s a great analogy — and it’s essentially exactly how the scoring works. MOROW awards a 3× “Pioneer” multiplier for paths never walked on the app, dropping to 2× “Rare” (walked 1–4 times) and 1× “Established” (5+ times). The Waze parallel is a good one too. The app is now open source at codeberg.org/morow/morow.

@tastrax:

Glad to hear it resonates. MOROW has since been built — it records GPS traces, uploads them to OSM automatically, and scores you more points the rarer the path. Open source at codeberg.org/morow/morow. Still in development but the core walk logging is working.

Around five months have passed since I posted this proposal, and I owe this thread some responses and an update. Apologies for the delay.

On the comments

SimonPoole and SomeoneElse both suggested taking this to the UK OSM forum, and I agree — that’s the right place for community consultation on a proposal of this scope. I haven’t done that yet, but it’s the clear next step before moving forward with any import or tagging schema work.

SomeoneElse also raised a fair challenge on tagging: I hadn’t fully thought through the active/disused/historic distinction. Many of these structures are no longer military in any meaningful sense — some are scheduled monuments, some are on private land, some have been demolished. disused:military=bunker combined with historic=* subtags is likely the right approach for decommissioned sites, with military=bunker reserved for active or ambiguous cases. I’ll work this up more carefully before the forum post.

BCNorwich flagged a bunker near Holme Hale, Norfolk not in the KMZ data I was using — a useful illustration of the problem. Thank you.

Pieter Vander Vennet mentioned MapComplete Studio as a route to building a verification theme. I’ll look at that — a MapComplete theme for bunkers would be an excellent fit for on-the-ground confirmation.

Related work

The bunker/pillbox proposal grew out of UKBOTA (UK Bunkers On The Air). Separately, I’ve continued working on OSM-contributing apps — MOROW (Maintaining Our Rights of Way), a Flutter app for logging and validating Public Rights of Way with automatic GPX upload to OSM, has been rewritten from scratch and is now open source at codeberg.org/morow/morow. I first wrote about the concept in this diary entry from June 2023: osm.org/user/chris_debian/diary/401813

Next steps on the bunker proposal

1. Draft a post for the UK OSM forum
2. Refine the tagging schema to handle active/disused/historic properly
3. Review MapComplete Studio for a verification workflow
4. Resume the UKBOTA gap analysis

@SimonPoole:

Good point, and apologies for the slow reply. I haven’t taken this to the UK forum yet — it’s still at the proposal stage. I do plan to post there once the approach is a little more developed. In the meantime I’d welcome any pointers to relevant prior discussions.

@BCNorwich:

Thank you — that’s a useful data point, and exactly the kind of community input this process will depend on. The KMZ data I was working from clearly has gaps, which reinforces the need for the kind of cross-referencing and community verification I was proposing.

@SomeoneElse:

Thanks for the detailed feedback, and apologies for not replying sooner. You raise a fair point about active vs disused vs historic — I hadn’t fully thought through the case where a structure is still standing but no longer has any military function. The tagging schema will need to account for that, and disused:military=bunker or historic=* with appropriate subtags would be the right approach for decommissioned sites. I’ll factor this into the proposal before taking it to the UK forum.

@Pieter Vander Vennet:

Thanks for the interest! A MapComplete theme for bunkers would be a great fit — especially for on-the-ground verification. I’ll take a look at MapComplete Studio. If you have any pointers on getting started, I’d welcome them.

Hi Eebie,

Thank you for this well-reasoned proposal. The distinction between inventoried and protected heritage is genuinely useful and the alignment with existing practice in France, the Netherlands, and others makes a strong case for adoption.

A few thoughts that might strengthen it further:

Wikidata linkage

Many Belgian heritage items, particularly protected ones, already have Wikidata entries, and the Flemish Erfgoed database is increasingly cross-referenced there. The proposal already recommends including URL links to inventory pages, which is helpful, but a wikidata=Q... tag is more robust: it is language-neutral, stable over time, and allows Wikidata’s heritage designation property (P1435) to be queried across countries. It might be worth proposing wikidata=* as a recommended companion tag wherever a Wikidata item exists, alongside the inventory URL. This would also make the data more useful to consumers working across OSM and Wikidata together.

Ref tags for inventory IDs

The proposal notes that including an ID number is valuable for traceability in Flanders, which is a good point. It might be worth going a step further and proposing specific ref:* tag names for each agency, for example ref:erfgoedobjecten=* for the Flemish inventory and equivalent tags for IRP Wallonia and the Brussels inventory. Without a defined tag name, contributors will use inconsistent keys and the data becomes harder to query. Other countries have established this pattern successfully (for example ref:onroerenderfgoed=* is already in use for some Flemish items).

The German-speaking Community

The gap is fairly acknowledged. It might be worth adding a note to the proposed wiki page explicitly flagging it as unresearched and inviting contributors from that community to fill it in, rather than leaving the wiki looking incomplete without explanation.

Minor corrections

There are a couple of small typos in the closing questions: “German-speeking” and “propasal” are worth fixing before this goes to a wider audience.

Overall this is a well-motivated proposal and I hope it gets the support it deserves.

Chris

Brilliant!

Great to hear; are you also using StreetComplete?

https://streetcomplete.app/

Chris

Hi H@mlet,

You raise a fair point about the snapped traces — you’re right that OSRM output can’t independently verify road access or passability.

I think the most valuable output here is actually the 19 unmatched segments, the ones OSRM couldn’t snap to anything. Those point to roads the trucks genuinely drove on that aren’t in OSM yet. The underlying telematics data is real survey evidence; OSRM snapping is just the filter that separates “already mapped” from “potentially missing”.

The snapped traces themselves are perhaps less interesting, but as Arjun notes, he’s verifying the unmatched candidates against aerial imagery before making any edits — so no router output is going into OSM unchecked.

Chris

Hi Arjun,

Really interesting approach. Using OSRM to route-match segment-based telematics data is an elegant solution to what is otherwise a frustrating data quality problem. The 19 unmapped road candidates from just two months of data shows how much potential there is in this kind of pipeline.

I am curious whether you see this scaling beyond Kerala. Commercial vehicle telematics is a global dataset; logistics operators, bus fleets, and freight companies exist everywhere, and many regions have the same gap between what is in OSM and what vehicles are actually driving. A replicable, documented workflow (your Python, OSRM and gpxpy stack sounds like a good basis) could be valuable for OSM communities in other countries, particularly where aerial imagery is sparse or outdated.

Have you thought about packaging this up as a reproducible tool or writing it up more formally? Publishing it on Codeberg or GitHub with a good README and some example data would make it easy for other OSM communities to pick up and adapt. It feels like the kind of thing that could get traction well beyond Kerala.

One thing worth considering as the pipeline scales is privacy. Even anonymised commercial vehicle traces can potentially reveal driver behaviour, working patterns, or commercially sensitive routes. It may be worth documenting the consent chain from the telematics provider through to OSM contribution, and noting any anonymisation steps taken, such as stripping timestamps before upload. This would also strengthen the case for wider adoption.

Great work, and good luck with the JOSM review of the unmapped candidates.

Chris

Interesting post, and the quarry example really illustrates the point well. The physical feature persists even when the function has ended, which is quite different from a closed restaurant.

Janjko’s apartment building example points at the same underlying principle: the lifecycle prefix system works well where the thing genuinely ceases to exist as that thing (a closed restaurant is no longer a restaurant), but becomes awkward where the form remains while only the use has changed. In those cases disused=yes as a modifier feels more honest than prefixing the primary tag.

One dimension I don’t think has been fully explored in the comments is reversibility. disused=yes seems to carry an implicit sense that something could return to use (the empty flat, the fountain awaiting repair), whereas disused:amenity=* implies something more permanent. Whether that distinction is intentional or just emergent from mapper habit is probably worth documenting somewhere.

Thanks,

Chris

I can see the village is now mapped. Have you thought about adding local knowledge, using StreetComplete? https://streetcomplete.app/

You will need access to a smartphone to do this.

Thanks,

Chris.

The OSM tag wiki should help. I find this from one of the linked reports:

https://taginfo.geofabrik.de/europe:united-kingdom/tags/plant%3Asource=solar#map

Chris

Nice work.

Thanks for the clarification Marcos, makes sense to keep the edits manual for accuracy.

I had a go at tidying up the script a little, in case it’s useful. The main changes:

• Swapped os.system() for subprocess.run() — a bit safer and more Pythonic
• Added an input() pause between objects so they open one at a time rather than all at once
• Used a context manager for the DB connection
• Added a HAVING count(*) < N filter to focus on the long tail and skip common valid values
• Added a KNOWN_GOOD set to skip values you already know are fine
• Added comments explaining the negative-ID-means-relation behaviour (I didn’t know that, good to learn!)

Revised script below. Sorry about the formatting, the diary interprets hash/ pound as bold font, they should be comments in the script. Happy to be ignored if you prefer your original — it clearly does the job! :)

Chris

Revised script

```python #! /usr/bin/env python3 “”” fix_osm_tags.py - Find and manually correct wrong highway tag values in OSM.

Requires a local osm2pgsql rendering database (e.g. ‘europe’). Workflow: 1. Queries planet_osm_line for highway values, rarest first (long tail first). 2. For each rare value, opens the OSM editor in your browser one object at a time. 3. You review, correct or leave a note, then press Enter to continue. “””

import subprocess import sys

import psycopg2

— Configuration —

DB_NAME = “europe” BROWSER = “librewolf” BROWSER_PROFILE = “default”

Highway values that are known-good and should be skipped.

# Expand this list to avoid being prompted for valid rare values. KNOWN_GOOD = { “residential”, “track”, “path”, “footway”, “cycleway”, “service”, “unclassified”, “tertiary”, “secondary”, “primary”, “trunk”, “motorway”, “living_street”, “pedestrian”, “steps”, “motorway_link”, “trunk_link”, “primary_link”, “secondary_link”, “tertiary_link”, }

Only show groups with fewer than this many occurrences.

# Keeps the focus on the long tail of rare/likely-wrong values. MAX_COUNT = 50

def open_in_editor(osm_id: int) -> None: “"”Open the OSM web editor for a given osm2pgsql osm_id.

In osm2pgsql rendering databases, negative IDs represent relations;
positive IDs represent ways.
"""
if osm_id < 0:
    # Negative ID => relation
    url = f"https://www.openstreetmap.org/edit?relation={-osm_id}"
else:
    # Positive ID => way
    url = f"https://www.openstreetmap.org/edit?way={osm_id}"

subprocess.run([BROWSER, "-P", BROWSER_PROFILE, url], check=False)

def main() -> None: with psycopg2.connect(dbname=DB_NAME) as db: cursor = db.cursor()

    # Fetch highway values ordered by frequency ascending (rarest first).
    # HAVING filters out common values that are unlikely to be errors,
    # keeping the focus on the suspicious long tail.
    cursor.execute(
        """
        SELECT
            count(*) AS count,
            highway
        FROM planet_osm_line
        WHERE
            highway IS NOT NULL
        GROUP BY highway
        HAVING count(*) < %s
        ORDER BY count ASC
        """,
        (MAX_COUNT,),
    )
    groups = cursor.fetchall()

    for count, highway in groups:
        # Skip values we already know are valid.
        if highway in KNOWN_GOOD:
            continue

        print(f"\n{'='*50}")
        print(f"Value: '{highway}'  ({count} occurrence{'s' if count != 1 else ''})")
        print("Press Enter to open each object, or type 's' to skip this group.")

        choice = input("> ").strip().lower()
        if choice == "s":
            continue

        # Fetch all OSM IDs with this highway value.
        cursor.execute(
            """
            SELECT osm_id
            FROM planet_osm_line
            WHERE highway = %s
            """,
            (highway,),
        )
        osm_ids = [row[0] for row in cursor.fetchall()]

        for i, osm_id in enumerate(osm_ids, start=1):
            print(f"  Opening {i}/{len(osm_ids)} (osm_id={osm_id}) ...")
            open_in_editor(osm_id)

            # Note: if the object no longer exists in OSM, the editor
            # will open a view of the whole planet — just close that tab.
            if i < len(osm_ids):
                next_action = input("  Press Enter for next, or 's' to skip rest of group: ").strip().lower()
                if next_action == "s":
                    break

    print("\nAll done!")

if name == “main”: sys.exit(main()) ```

Nice script, Marcos! Would you be able to share an example of a ‘before’ and ‘after’ tag?

Thanks,

Chris