Automated edits/DepositAppBot
This page documents a proposed automated edit per the Automated Edits code of conduct.
About
Deposit is a mobile app, currently in development, that helps people find deposit-return (statiegeld) locations in the Netherlands. Its location data comes from OpenStreetMap via the Overpass API. Users file corrections from inside the app while physically at a location — corrected opening hours, changed accepted materials, or a confirmation that a machine is there.
This proposal is to contribute those corrections back to OpenStreetMap via a scheduled batch job running under a dedicated account, DepositAppBot (to be registered once this discussion settles).
Operator
- Bot account: DepositAppBot (not yet registered; will link back here and to the operator)
- Operator: jacque on openstreetmap.org (forum: jacque1; this wiki page is maintained by the same person under the wiki account Eugen)
- Contact: changeset comments on the bot account are monitored and answered; the operator can also be messaged directly.
What the edits are
Only objective, human-observed facts. Every correction originates from a user standing at the location, and every correction is reviewed by a human moderator before it is queued for upload — the bot mechanises the upload, not the judgment.
Tags affected, on machine elements only:
opening_hoursrecycling:cans,recycling:glass_bottles,recycling:plastic_bottles,recycling:refund_bottle_crates— always=yes, only for what the visitor confirmed, never=novending=bottle_return- Position and address corrections of existing elements
Material tags go on the machine, never on the shop. In the Netherlands every recycling:cans is on amenity=recycling and none is on a shop=* element; the bot follows that and never adds recycling:* or vending=* to a shop=supermarket.
Crates: an earlier version of this page named recycling:crates, which has never been used. The documented key is recycling:refund_bottle_crates (0 uses in NL at the time of writing); the bot does not write it until the community has answered the tagging question in the thread.
Explicitly out of scope:
- Removing anything. Settled in the discussion: a "no machine here" report stays in the app as a warning for a mapper to check by hand. The bot never removes
vending=bottle_returnand never deletes an element. - Free-text content, opinions, or transient status ("machine is broken today")
- Any data derived from third-party databases — corrections are user surveys, nothing else
Creating a machine node
Proposed extension, put to the discussion on 2026-09-02. Not part of the pilot. It comes back to the thread as its own step once the questions below are answered, and no node is created before that.
OpenStreetMap knows about 60 bottle-return machines in the Netherlands, against roughly 4000 supermarkets that have one. The app asks a visitor standing in the shop a one-tap question — "Is there a return machine here?" — and a confirmed yes, reviewed by a moderator, would become one new node per confirmed shop, in its own changeset:
- The machine tag is being decided by the NL community in Poll: Statiegeld (opened 2026-09-12), between
amenity=vending_machine+vending=bottle_return(about 4100 uses; the current method on this wiki and the iD preset) andamenity=recycling+recycling_type=reverse_vending_machine(about 2500, almost all from one undiscussed import in Portugal). The bot writes exactly the winning tagging and nothing else; if it starts before the poll closes it usesvending=bottle_returnand retags its own nodes afterwards. recycling:cans=yes,recycling:plastic_bottles=yes;recycling:glass_bottles=yesandrecycling:refund_bottle_crates=yesonly when the visitor confirmed them; never a=noindoor=yesopening_hoursonly when they differ from the shop's
Placement: inside the supermarket's outline, or at its node when the shop is a node — a visitor confirms that there is a machine, not where in the shop it stands.
Duplicate check: before creating, the job looks for an existing vending=bottle_return (or recycling_type=reverse_vending_machine) within the shop's outline or a short distance of it, and skips.
Answered in the thread so far (posts 21–30):
- Placement: exact position is preferred; for the first phase, shop position with a small random offset and
fixme=locatie geschatis acceptable, and the bot moves the node and drops the fixme once a visitor pins the real spot. - Duplicates: a distance check is enough. One machine, one node; the count of machines at a shop is useful information. The app will group machines by the shop they are in before any creation, so a report or edit can name the machine it is about.
- Intent: new POIs inside the shop, the way ATMs are mapped — not tags on the shop element.
Still open:
- Which machine tag — see the poll above. The bot follows the result.
- Whether creation at this scale should follow the Import/Guidelines rather than only the Automated Edits code of conduct — asked in post 19, not yet answered either way.
- A key for bottle crates:
recycling:refund_bottle_crateswas added to this wiki by one person without discussion. The operator will open a tagging discussion proposing a crates key once the machine tag is settled; until then the bot writes nothing for crates.
Method and frequency
- A scheduled server-side job (roughly daily) uploads the moderator-approved queue.
- Region: Netherlands only.
- Volume: low — this is a correction stream driven by individual user reports, not an import. Expected well under 50 changed elements per week; if node creation is accepted, the same order of magnitude in created nodes.
- One changeset per correction, so each changeset references exactly one anonymised report and can be reverted on its own. A correction is submitted exactly once (tracked by changeset ID on our side).
- Optimistic locking: a version conflict re-reads the element once and recomputes the change against the fresh copy — never resends the stale one. A second conflict means a human is editing right now and the bot leaves the element alone.
- The job is piloted against the development sandbox first, then as a small hand-reviewed live batch announced in the forum thread before any unattended operation.
Relationship to the Import guidelines
For modifications of existing elements we believe this falls under the Automated Edits code of conduct rather than the Import/Guidelines: no external dataset is merged, no conflation is involved. Every change is an individual human's on-site observation applied to an existing element — survey data whose upload is mechanised, not a dataset being imported. Only survey-originated corrections are eligible (no third-party data), and a human moderates every change.
Node creation (above) is the part that could be read as import-shaped by scale. That question is put to the community explicitly, and if the answer is that it should follow the import process, it will.
Changeset tags
created_by=the app and its versionbot=yessource=surveycomment=a human-readable description of the changewebsite=https://wiki.openstreetmap.org/wiki/Automated_edits/DepositAppBotdeposit:edit=an opaque id for the originating in-app report, resolvable only by the operator — never anything that identifies the person who filed it
Licence
Before any correction is uploaded to OpenStreetMap, the app tells users at the point of submission that their contribution is published under the ODbL. This notice is a precondition of operation: it ships before the first upload, and only corrections filed after the notice exists are eligible for upload — nothing collected before users were told will be pushed. Corrections are the user's own on-site observations; no third-party data is involved.
Quality control
- Human moderation gates every upload — nothing user-submitted reaches OSM unreviewed.
- Only fields the user explicitly corrected are touched; all other tags on the element — and a way's nodes or a relation's members — are preserved verbatim.
- A correction the source has already caught up with is not sent; a proposal identical to what the element already says produces no changeset.
- Conflicts (element changed upstream since the correction was filed) cause a single re-read and recompute, then the correction is held for re-review, never force-applied.
- A duplicate check runs before any node creation (see above).
Revert plan
- Every upload's changeset ID is stored in the project backend, so the bot's entire history is enumerable, and each changeset holds exactly one correction.
- The revert path (JOSM reverter) is tested against a sandbox changeset of our own before the first live batch.
- If a systematic error is detected, uploads stop immediately and affected changesets are reverted.
- Any community member can request a stop via changeset comment or a message to the operator — the job does not run again until the concern is resolved.
Status
- Proposed — awaiting community discussion. No edits, and no bot account, until at least two weeks of discussion have passed and concerns are addressed.
- 2026-08-29: proposal posted.
- 2026-09-02: removals dropped from scope; crates key corrected; node creation proposed as an extension with three open questions.
- 2026-09-10: pilot narrowed to modifications of existing elements only —
opening_hoursand material tags on machines that are already mapped, sandbox first, then a small hand-reviewed live batch announced in the thread. Node creation, the machine tag, the crates key and the import question stay open and come back to the thread as their own step before any node is created. - 2026-09-12: the NL community opened Poll: Statiegeld on the machine tag and the statiegeldwinkel tag; the bot follows its outcome.