Proposed QA tool: comparing Swiss Post letterbox data with OSM (Switzerland)

[wintifrosch]

Hi,

I would like to ask for early community feedback on a proposed QA project
related to post boxes in Switzerland (amenity=post_box).

Important upfront:

• This is not intended as an automated edit, import, or a “single source of truth”.
• The goal is to support mappers with structured review hints, not to overwrite OSM data.

---

Background

In Switzerland, Swiss Post publishes a public Standortsuche (location search)
which currently lists about 13’850 letterboxes (Briefeinwurf), including:

• locations of letterboxes,
• emptying deadlines (collection times).

From an initial analysis, these data appear relatively stable, but changes to
locations and collection_times do occur over time.

At the same time, a first snapshot of OSM data for Switzerland suggests that
post_box coverage and metadata completeness vary, for example:

• about 7’400 OSM objects tagged with amenity=post_box,
• a significant share without collection_times,
• many objects without any check_date or check_date:collection_times tag.

These figures are intended as indicative observations only, not as a judgement
on data quality.

---

Project idea (QA-focused)

The idea is to build an open, transparent QA tool that:

1. Periodically fetches public Swiss Post letterbox data.
2. Compares them spatially with existing OSM amenity=post_box objects.
3. Produces review artefacts only, for example:

• GeoJSON layers for visual inspection (e.g. uMap / JOSM),
• CSV lists of potential review candidates,
• optional MapRoulette-style tasks (later, if appropriate).

→ No automatic uploads to OSM are planned.

Project repository (early prototype):
GitHub - swisspost-postbox-qa/worker: Tools to compare postbox objects in OSM and «Swiss Post Standortsuche»
Minimal project status page:
Swiss Post – Postbox QA (Prototype)
A small set of example QA outputs (limited test area) is available in the GitHub repository for illustration.

Intended outputs (examples)

• Possible update:
  “OSM post_box at location X has collection_times missing or older than Swiss Post information (checked YYYY-MM-DD).”

• Possible discrepancy:
  “Swiss Post lists a letterbox near location X, but no corresponding OSM object was found within N meters.”

• Possible review case:
  “An OSM post_box exists, but Swiss Post no longer lists it — please verify on the ground.”

In such cases, the tool would suggest review-oriented tags such as:

• check_date:collection_times=*
• fixme=* (sparingly, and only to prompt human review)

→ No automatic deletions are intended.

---

Data philosophy

• Swiss Post is not considered a single point of truth.
• OSM ground truth and local knowledge always take precedence.
• The tool is meant to highlight differences, not to decide which data are “correct”.

Overall, this project is closer in spirit to Osmose, MapRoulette, or other QA layers
than to an import or bot.

---

Operational model (high level)

• Multiple independent volunteers may run the crawler (for redundancy).
• Runs are intentionally infrequent (e.g. weekly).
• Outputs are published openly (GitHub / project website), with timestamps and sources.
• Human mappers decide if and how any changes are applied to OSM.

---

Questions for the community

I would very much appreciate feedback on the following points:

1. Does this QA-oriented approach align with OSM best practices?
2. Are there known pitfalls when using operator-published data in this way?
3. Is check_date:collection_times=* a reasonable tagging approach in this context?
4. Would you recommend treating this as an “Automated Edit”, an “Import”, or purely as a QA tool?
5. Are there similar projects (in other countries) that would be useful to study?

I am intentionally asking for feedback before scaling this beyond a prototype.

Thank you very much for your time and for any guidance you are willing to share.

Best regards,
Daniel

[Fjellrev]

Der erste und wichtigste Punkt ist: Sind die Daten von der Lizenz her mit Openstreetmap kompatibel?

Soweit ich mich erinnere sind sie das nicht und können damit auch nicht als Grundlage für ein QA-Tool verwendet werden.

Sorry für die potentielle Spassbremse, aber vielleicht habe ich ja Unrecht.

[habi (David Haberthür)]

Wie schon bei Talk:Switzerland/amenity=post box - OpenStreetMap Wiki geschrieben, habe ich auch das Gefühl, dass wir die Lizenzfrage von https://places.post.ch/ schon mal (abschlägig) diskutiert haben. Ich finde aber den Diskussionsstrang auf der Schweizer Mailingliste nicht mehr.

[wintifrosch]

Thank you both for raising this – the licensing question is indeed essential.

I fully agree that Swiss Post data is not license-compatible for copying or importing into OpenStreetMap, and this project does not aim to do that.

The important distinction I would like to make is the following:

The Swiss Post “Standortsuche” is used only as a reference signal, not as a dataset to be copied, redistributed, or transferred into OSM.
The project does not reproduce or publish Swiss Post content (no tables, no complete lists, no collection_times values), and it does not treat Swiss Post as a single point of truth.

Instead, the tool derives QA hints only, such as:

• “this OSM post_box may be missing collection_times – please verify on the ground”
• “Swiss Post lists a letterbox near this location – please check whether an OSM object exists”
• “an OSM post_box exists, but Swiss Post no longer lists it – ground verification suggested”

Any resulting OSM edits are intended to be made manually by human mappers, based on on-the-ground verification and local knowledge – not by copying operator data.

In that sense, the approach is closer to existing QA practices such as:

• Osmose-style issue detection,
• MapRoulette tasks derived from reference signals,
• QA layers that highlight potential inconsistencies without asserting correctness.

I agree that this distinction needs to be made very explicit (and I am happy to clarify it further if needed), but my understanding is that using external sources as reference signals for human QA is fundamentally different from copying or importing their data into OSM.

Feedback on whether this distinction is sufficiently clear – or how it could be improved – is very welcome.

PS:
To make the scope and legal considerations explicit, I have added a short «Legal considerations» section to the project website and the README.md on GitHub, clarifying that Swiss Post data is not redistributed and only derived QA hints are published.

For completeness, a short note was also added to the relevant OSM Wiki talk page for «Switzerland/amenity=post box» to point to this community discussion, so that feedback is not split across channels.

[Robert_Whittaker]

FYI: Here’s a tool that I run for postboxes in the UK, which sounds very similar to what you’re proposing: https://osm.mathmos.net/postboxes/.

[Fjellrev]

@wintifrosch

Instead, the tool derives QA hints only, such as:

• “this OSM post_box may be missing collection_times – please verify on the ground”
• “Swiss Post lists a letterbox near this location – please check whether an OSM object exists”
• “an OSM post_box exists, but Swiss Post no longer lists it – ground verification suggested”

Any resulting OSM edits are intended to be made manually by human mappers, based on on-the-ground verification and local knowledge – not by copying operator data.

Sorry aber das tönt mir jetzt doch etwas sehr nach Zurechtbiegen damit es irgendwie passt.

Du willst die Daten verwenden um Hinweise zu generieren die manuell überprüft werden müssen. Wie willst du das regelkonform machen ohne die Daten zu verwenden?

Die einzige Art wie ich mir vorstellen kann die Daten zu nutzen (und wie es auch schon gemacht wurde): StreetComplete fragt ob ein Briefkasten noch existiert. Er wird vor Ort nicht gefunden. Auf der Standortsuche schauen ob er noch existieren sollte, und dann entscheiden ob löschen oder weiter suchen.

Also die Post-Daten verwenden nachdem der manuelle Prozess stattgefunden hat.

[9_tab]

Random fact: 2 of 3 mailboxes I used recently aren’t in OSM.

Can the question be split between location and collection times?

The first appears more important and less frequently changing than the second. Maybe proper licensing can be obtained for locations. If a location isn’t in their database, that could be a mayor problem.

[wintifrosch]

Thank you for the follow-up — I understand the concern, and I agree that the
boundary between “using a reference” and “using a dataset” needs to be handled very carefully.

TL;DR: A licence-conservative QA approach appears feasible even without directly linking Swiss Post data to OSM objects.

The primary goal of the project is OSM-internal data quality, not a systematic comparison between Swiss Post and OSM datasets.

Based on the concerns raised in the discussion (in particular regarding licensing), it seems adequate to further narrow the intended scope.

More concretely:

1. OSM-first review model
   The focus is on ensuring that existing amenity=post_box objects in OSM are periodically reviewed and carry an explicit review timestamp
   (e.g. check_date, check_date:collection_times).
   This can be done entirely independently of any external source.

2. External data only as a temporal trigger, not as a reference dataset
   Swiss Post’s “Standortsuche” would be observed over time only, similar to how one monitors whether a webpage has changed.
   Detected changes would merely trigger an earlier OSM review for the affected area or object — without transferring, mirroring or publishing any Swiss Post attributes.

   In other words, the tool would use the “Standortsuche” not to answer what changed, but only that something may have changed, prompting on-the-ground verification.

3. No publication or reuse of Swiss Post data

   • No Swiss Post datasets (full or partial) are published.
   • No attributes such as collection times are copied or derived.
   • The only output is a generic QA hint like “please re-check this OSM object”.

In this form, the workflow is close in spirit to StreetComplete or other review-based QA approaches: external information may motivate a check, but the actual OSM edit is always based on local observation and mapper judgement.

@Fjellrev
The periodic review mentioned in point (1) does not explicitly distinguish between location and collection times, but it would ensure that all data are re-checked within an appropriate timeframe.

If even this reduced, trigger-based use of the Swiss Post «Standortsuche» were to be considered problematic, I would prefer to pause or further restrict the approach until more clarity is available.