Automated edits/deposit nl

This is a proposal under discussion — no automated edits have been made. Discussion: forum thread (OSM Community Forum, Netherlands). Updated 2026-09-22: both parts of the bot are built and switched off. The first run is proposed for Monday 28 September 2026, at most five changesets, unless someone objects in the thread before Sunday 27 September — see Proposed next step. The account deposit_nl exists and has made no edits; the sandbox run and a revert drill are done; the poll on the machine tag has closed.

This page documents a proposed automated edit per the Automated Edits code of conduct. It was previously titled Automated edits/DepositAppBot; the account was registered as deposit_nl, and the page follows the account.

About

Deposit is a mobile app that helps people find deposit-return (statiegeld) locations in the Netherlands. It is in open testing on Google Play (Android). Its location data comes from OpenStreetMap. Users standing at a location answer questions and file corrections in the app — is there a return machine here, what does it accept, when is it open.

This proposal is to contribute that back to OpenStreetMap through a scheduled job running under a dedicated account, deposit_nl.

Operator

• Bot account: deposit_nl — registered 2026-09-17, no edits yet. It is used for nothing else.
• 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. A request to stop is honoured immediately.

What the edits are

Only objective, human-observed facts. Every change originates from people standing at the location, and every change is reviewed by a human moderator before it is queued for upload — the bot mechanises the upload, not the judgment.

There are two kinds of edit. Both are built, and both are switched off until the community has answered.

1. Adding tags to machines that are already mapped

Only on elements already tagged as a return machine (vending=bottle_return or recycling_type=reverse_vending_machine) — about 60 in the Netherlands:

• recycling:cans=yes, recycling:plastic_bottles=yes, recycling:glass_bottles=yes — only for what visitors confirmed; always =yes, never =no
• opening_hours — only when the element has none. A mapper's existing value is never replaced.

Every other tag on the element, and a way's nodes or a relation's members, are preserved exactly.

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=*; the bot follows that. The code refuses a materials edit on any element that is not a machine, and no shop=supermarket element is ever edited.

2. Creating a machine node where a supermarket has one and OSM does not

See below.

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 a tag and never deletes an element.
• A key for bottle crates. An earlier version of this page named recycling:crates (never used) and then recycling:refund_bottle_crates; the discussion pointed out the latter was added to this wiki by one person without discussion. The bot writes no crates key until one is agreed; the operator will open a tagging discussion for it.
• Position or address corrections of existing elements — not built, and would be announced in the thread first.
• Free-text content, opinions, or transient status ("machine is broken today")
• Anything derived from third-party databases, chain lists or inference. Surveys, nothing else.

Creating a machine node

Proposed in the thread on 2026-09-02, requested on 2026-09-19 (posts 32–35). Built on 2026-09-22 and switched off — a separate switch from the one for edit 1. No node is created until the community has answered; see Proposed next step.

OpenStreetMap has about 60 return machines in the Netherlands, against roughly 4000 supermarkets that have one. The aim is that every supermarket which has a machine gets one mapped — at the pace people actually visit shops.

Where a node comes from. Never from a list and never from a guess. The app asks a visitor on the location screen: "Is there a return point here?". A node is proposed only when:

• at least two different visitors answered yes at that shop, each after being told their answer is published under the ODbL, and
• a human moderator approved it, and
• the shop is already an element in OSM, and still is when the node is about to be created, and
• there is no machine mapped within 50 m of it, under either tagging, checked against OSM as it is at that moment.

So source=survey is true for every node.

What is created — one node per shop, one changeset per node:

• amenity=vending_machine + vending=bottle_return. The NL poll closed on 2026-09-19 at 6 for recycling_type=reverse_vending_machine, 5 for this tagging and 1 other; with no clear majority the poll's organiser advised the current default. The app reads both taggings. If a better value comes out of a wider discussion or a formal proposal, the bot follows it and retags its own nodes.
• recycling:cans=yes, recycling:plastic_bottles=yes, recycling:glass_bottles=yes — only for materials visitors vouched for at that shop: the materials OSM already lists for the shop once enough visitors confirmed them, or a visitor's correction a moderator accepted. Never a value the app assumed, and never =no. Otherwise none.
• indoor=yes or indoor=no — only when a visitor has said which. A default of indoor=yes was proposed on 2026-09-19 and withdrawn the same day after an objection in the thread (post 34): some share of those tags would be wrong. Until the app asks the inside/outside question, the key is not written.
• fixme=locatie geschat — on every created node, because the position is an estimate.

Nothing is copied from the shop element, and the shop element is not modified.

Position. 5 to 8 metres from the shop's node, towards the inside of the building it sits in; fixed per shop, not random. Closer than about 5 m and the two icons overlap at zoom 19, where vending machines render; the aim is that shop and machine are separately visible and selectable. The direction comes from the building outline: most supermarkets here are nodes at the address point on the entrance side, so a random direction would put half the machines in the street or the unit next door. The node moves along the line from the shop towards the centre of the building that contains it, and is pulled back towards the shop if needed to stay inside the outline — never closer than 5 m. Measured on 2026-09-19, the shop node lies inside a mapped building for about 97% of supermarket nodes in Amsterdam and 92% in Groningen. A shop outside every building is placed towards the nearest one; only when no building is mapped within 50 m is a fixed direction derived from the shop's id used. When the app later lets a visitor pin the exact spot, the bot moves the node and removes the fixme.

One machine, one node. The first version creates one node per confirmed shop. A second machine at the same shop is only added once a visitor can place it.

Answered in the thread (posts 21–36):

• Exact position is preferred; an estimated position with a small offset and fixme=locatie geschat is acceptable for the first phase.
• A distance-based duplicate check is enough; the number of machines at a shop is useful information.
• The intent is new POIs inside the shop, the way ATMs are mapped — not tags on the shop element.
• No indoor default (post 34).
• Support for the plan as a whole (post 36), with the suggestion that the rules could later be relaxed per contributor once the first batches have been checked.

Proposed next step

Unless someone objects in the thread before Sunday 27 September 2026, the job starts on Monday 28 September 2026 with both kinds of edit, at most five changesets per run, and the ids of each run posted in the thread.

On the import question: nobody in the thread has asked for the import process, and the operator reads this as an automated edit rather than an import — there is no external dataset, and every node comes from people standing in the shop, moderated one at a time. If the community asks for the import process before 27 September, it will be followed before the first node.

Method and frequency

• A scheduled server-side job, once a day, uploads what moderation has approved.
• Region: Netherlands only.
• At most five changesets per run to begin with, shared between edits and created nodes. The changeset ids of a run are posted in the forum thread, and the ceiling is raised only after the community has looked at them.
• One changeset per correction or created node, so each can be reverted on its own. A correction's changeset references one anonymised report; a created node's references the shop it belongs to. Each 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 can be stopped at once by the operator without a deploy; node creation has a separate switch of its own, which is off.
• Tested end to end on the development server on 2026-09-17: changeset 680507 added two tags to a test node and kept all its other tags.

Relationship to the Import guidelines

For additions to existing elements we believe this falls under the Automated Edits code of conduct rather than the Import/Guidelines: no external dataset is merged and no conflation is involved. Every change is people's on-site observation applied to an existing element — survey data whose upload is mechanised. A human moderates every change.

Node creation is the part that could be read as import-shaped by scale, even though each node rests on two visitors' confirmations and not on a dataset. The operator's reading is that it is an automated edit; the question is open in the thread until 27 September, and if the answer is that it should follow the import process, it will, before the first node.

Changeset tags

• created_by= the app and its version
• bot=yes
• source=survey
• comment= a human-readable description of the change
• website=https://wiki.openstreetmap.org/wiki/Automated_edits/deposit_nl
• deposit:edit= on a correction: an opaque id for the originating in-app report, resolvable only by the operator
• deposit:shop= on a created node: the OSM element of the shop the machine belongs to (for example node/123456), since no single report is behind a creation

Neither ever carries anything that identifies a person.

Licence

The app tells users at the point of submission that their contribution is published under the ODbL. Only contributions made after that notice was shown are eligible for upload — nothing collected before users were told is pushed, and the rule is carried per contribution, not per date. Contributions are the users' own on-site observations; no third-party data is involved.

Quality control

• Human moderation gates every upload — nothing user-submitted reaches OSM unreviewed.
• Only what was confirmed is written; all other tags are preserved verbatim.
• Something OSM already says produces no changeset.
• A value the app merely assumed for a supermarket is never uploaded, only what a visitor confirmed or changed.
• A materials edit on an element that is not a machine is refused.
• Before any node creation, a live read of OSM around the shop checks that the shop still exists and that no machine is mapped within 50 m.

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 change. For created nodes the node id is stored beside it.
• The revert path was exercised on 2026-09-17: sandbox changeset 680507 was reverted with JOSM's reverter as 680508; the node's history shows all three versions, and the procedure is written down as a runbook.
• A revert is made by the operator under his own account, not by the bot.
• If a systematic error is detected, uploads stop immediately and the 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 — under community discussion. No edits have been made.
• 2026-08-29: proposal posted.
• 2026-09-02: removals dropped from scope; crates key questioned; node creation proposed.
• 2026-09-10: a first step limited to existing machine elements described in the thread.
• 2026-09-12 to 2026-09-19: NL poll on the machine tag — 6 / 5 / 1, no clear majority; the bot writes the current default vending=bottle_return.
• 2026-09-17: account deposit_nl registered (no edits). Sandbox run (changeset 680507) and revert drill (680508) done.
• 2026-09-19: node creation requested in the thread (posts 32–33), with the gate, tags and position rule described above. An indoor=yes default was withdrawn after an objection (post 34); the key is written only from a visitor's answer.
• 2026-09-20: the app entered open testing on Google Play (post 38); support for the plan in the thread (post 36).
• 2026-09-22: node creation built and switched off. First run proposed for Monday 28 September, unless there are objections, or a request for the import process, before Sunday 27 September.

See also

• Automated Edits code of conduct
• Import/Guidelines
• vending=bottle_return
• Tag:recycling_type=reverse_vending_machine