I am the developer of the “Deposit” app, a mobile app currently in development, helping people find deposit-return (statiegeld) locations in the Netherlands. The app’s location data comes from OSM via Overpass. Users provide corrections through the app based on being physically at the machine — correcting opening hours, updating accepted materials, or reporting that a machine is gone.
I would like to contribute this feedback back to OpenStreetMap via a scheduled batch job (roughly daily), following the Automated Edits code of conduct.
Proposal summary:
Data: objective facts only, each originating from an on-site observation and reviewed by a human moderator before anything is pushed: opening_hours, material tags (recycling:cans, recycling:glass_bottles, recycling:plastic_bottles, recycling:crates), vending=bottle_return, and position/address corrections of existing elements. No new elements, no free text, no third-party data. (One heads-up: I may later propose creating a deposit-point element at venues OSM already maps, from moderated on-site observations — if so, I’ll bring that back to this thread before any such edit happens.)
Absence: if a user reports “no deposit point here” and moderation confirms it, we would like to reflect the removal upstream — I’d specifically like your view on whether deletion-shaped edits should be in the bot’s scope at all, or left to manual review.
Account: a dedicated project account (e.g. DepositAppBot), linked to my personal account as operator. I commit to answering changeset comments on it.
Attribution: changeset tags identify the app (bot=yes, source=survey) and reference the anonymised originating report.
Licensing: before the first upload, the app will tell users at the point of submission that their correction is released under the ODbL — and only corrections filed after that notice exists will be eligible for upload.
Revert plan: every changeset ID is tracked on our side, and the revert path is tested before the first live batch. The pilot runs on the dev sandbox first, then as a small hand-reviewed live batch announced in this thread.
On the Import guidelines: I read this as a mechanical edit stream under the Automated Edits code of conduct rather than an import — no dataset is merged, no conflation, no element creation; each change is one person’s on-site observation whose upload is mechanised. If the community sees any part of it as import-shaped, I’m happy to follow the import process for that part too.
This sounds promising. I’m in favour of the initiative.
I recommend also adding the tag indoor=yes/no.
I’d like to suggest, as part of the quality control, to periodically check for machines that have been mapped very close to each other, to verify that the objects mapped aren’t duplicates. This sort of check can improve the user experience of people who are interacting with the Deposit App, and of course it’d be a positive contribution to OSM.
As for duplication - this only editing existing locations from OSM. So, not sure if I want solve location duplication by the deposit machines check. Unless, I understood the proposal wrong.
Zit er een bedrijf achter deze app? Is er een verdienmodel?
Dit is niet de Statiegeld App toch? ‘Deposit App’ is letterlijk de Engelse vertaling van de naam van die app van Verpact, dus je zit daar mogelijk met een merkenrechtkwestie.
Je host zelf een Overpass API instantie neem ik aan?
Verwijdervormige bewerkingen?
Deze tekst loopt grammaticaal gezien, maar die twee genoemde tags identificeren de app toch niet?
Hey hey, this is me, and I have zzp. I will check if I violate trademark - thanks!
I was planning to add one paid feature just to get into shipaton.com this year.
I proxy the Overpass API and do an overnight dump of Overpass data that the app uses if the proxy doesn’t reply in time. Maybe I can do this better or more properly; let me research the topic.
By deletion, I mean removing the bottle return tag from the location. It also looks like this post was disconnected from the wiki, where the changeset is described in more detail. Apologies!
For deletion, have you considered some form of soft-delete? Eg setting something as disused:* or something similar - perhaps with a fixme flag to draw attention to it for review?
Which leads to: Is there any form of review of the user-submissions? How is the quality of data ensured? Will users be able to add a picture (either for proof or uploading - and if for uploading, where will it be hosted)? With automation it’s the automator who’s responsibile for the data (and there’s a very big “ymmv” with third party app/members contribution in OSM’s track record), how are you planning on being in control? Which controls do you have in case of abuse, bad actors or just incompetent users?
Also: Now that I’m thinking of that… Why not just make a mapcomplete theme for this, if it doesn’t already exist? It feels a bit like reinventing the wheel.
Maybe I should clarify one important thing: Deposit does not show OSM data blindly. There is a backend in between, and some locations can also be inferred — for example, we may know there is a supermarket and assume it probably has a deposit machine.
I think I should make this origin explicit on the server: whether the machine comes from OSM, another source, or is inferred.
For inferred locations I also like the idea of asking the user a very simple question: “Is there a deposit machine here?” A Yes/No answer can immediately improve Deposit’s own data. It still should not directly trigger an OSM edit.
For OSM updates I agree that the bar should be higher, especially for removals. Transient things like broken/full machines belong only in Deposit. Durable corrections can become candidates for OSM, but should go through separate verification/moderation. I may also simply exclude destructive automated edits initially.
About photos: possible, especially as evidence for difficult cases, but I would rather not require them for normal reports because they add privacy, storage and moderation issues.
And thanks for pointing me to MapComplete. I don’t think it replaces Deposit, because Deposit is mainly a consumer app with its own server-side data/confidence model. But it may make sense to reuse MapComplete for the final OSM editing part instead of rebuilding that part myself. I’ll investigate it.
MapComplete updates OSM directly using the end user (personal) OSM-account. It can add and modify objects using presets, but not delete. For deletion, it can mark an object e.g. with a disused:- tag. You would have to build a MapComplete theme comparable to the Benches theme, which can then be used by the end users from the browser on most devices, no installation needed.
Instead of storing then propagating the changes, you would extract the changes from OSM to your specialised app (which you already do, I think?)
(It does remind me of the app AlleBankjes, built on its own data store, which has OSM as it’s main source. The user add, modify and (I think) delete benches from the app, but nothing gets propagated to OSM. Since AlleBankjes takes data without giving anything back, I stopped using it. )
Maybe some context about why I started Deposit. It actually started from my own frustration with deposit machines being broken or full when I arrive. I have a feeling many people have the same problem, so the original goal was simply to have more up-to-date information about whether a machine is usable. Only later I got deeper into where the location data comes from, OSM, how to correct it, etc.
The main problem I see with using MapComplete for all corrections is that every Deposit user would need an OSM account. For an OSM-oriented app that makes sense, but Deposit is meant for regular consumers. Requiring OSM registration/login just to report “this machine is broken” or “there is no machine here” feels like too much friction.
I also don’t want to end up in the AlleBankjes situation you describe. The idea is to give suitable permanent corrections back to OSM, instead of keeping an improved private dataset only in Deposit.
I will think about a separate option for users who already have an OSM account. Deposit could route them to a dedicated MapComplete theme, so they can make the correction directly in OSM.
So maybe both flows can coexist: easy and up-to-date reports in Deposit for regular users, direct OSM editing for users who want it, and a controlled way to propagate verified permanent corrections that otherwise would stay only in Deposit.
En opzich lijkt de aanpak goed, zorg er wel voor dat je niet in dezelfde fouten trapt als andere vergelijkbare apps.
Splits duidelijk de data wat wel en wat niet binnen scope is van OSM, dus bijvoorbeeld geen reviews of te veranderlijke data.
Gebruik tagging die al geacepteerd is, ga geen nieuwe tags pushen via de app.
Ik denk dat de aanpak met review goed is. Zorg ervoor dat je de mogelijkheid hebt om zelf data op te slaan en te combineren met de data vanuit OSM.
Automatisch verwijderen zou ik niet doen, levert meer problemen op dan voordelen, als de situatie zo gewijzigd is dat verwijdering van toepassing is dan moet de hele omgeving eigenlijk door een mapper gecontroleerd worden.
Ik zie dat statiegeldnederland een locatiewijzer heeft met denk (bijna) alle statiegeld locaties. Het zou naar mijn idee geen slecht idee zijn om met statiegeldnederland contact op te nemen en te vragen of je/we deze data mogen importen. Z’n import is ook niet zonder problemen maar waarschijnlijk een stuk makkelijker.
Daarmee zou de App zich kunnen beperken tot het doorgeven van verbeteringen.
I agree about deletion. After this discussion, I think automatic deletion should be out of scope. If a report suggests removing something from OSM, a mapper should check it manually.
Thanks, this helps me to make the boundaries much clearer.
Yes, I’ve already tried this. I contacted Statiegeld Nederland about access to their location data, but unfortunately I haven’t received a reply.
Right now I use OSM as the main source, but on the backend I also combine it with my own observations and information from the Statiegeld Nederland location finder. For example, I don’t blindly assume every supermarket has a machine—I try to give the location a more realistic confidence level based on the information I have.
Their data would of course be a very useful source if they were willing to provide it officially. And if they would also allow an OSM import, that could simplify things a lot.
Without explicit permission, though, I don’t think their location finder can simply be imported into OSM.
This is partly how I ended up with the current approach: use OSM as the base, add Deposit-specific information on top, and find a good way to send verified permanent corrections back to OSM.
I may try contacting them again, but so far I haven’t heard back.
Hey all, an update after checking our own proposal against taginfo and the wiki. Two corrections, and one change of scope I want to put to you properly.
1. Crates: I named a tag that does not exist.
The proposal and the wiki page say recycling:crates. Taginfo has zero uses of it, anywhere. The documented key on the vending=bottle_return page is recycling:refund_bottle_crates (16 uses worldwide, 0 in NL). So my crates question was half answered by the wiki already. I will correct the wiki page. Until the key has some real use in NL the bot will not write it, so no new tag gets pushed via the app.
2. Material tags belong on the machine, not on the shop.
Most deposit points in our data are shop=supermarket ways. In the Netherlands recycling:cans is on 906 elements and every one of them is amenity=recycling; zero are on a shop=*. So the bot will never add recycling:* or vending=* to a shop element. That would be inventing a pattern nobody in NL uses, which is exactly what Tjuro asked me not to do.
3. The scope change: adding the machine that OSM does not know.
In the first post I said the bot would not create elements. I want to bring that back now, because it is where the app can give the most back. OSM knows about 60 machines in NL; there are around 4000 supermarkets with one. The app is getting a one-tap question on the location screen: “Is there a return machine here?” (@Peter_Elderson, this is the “add” you asked about). A “yes” from a visitor standing in the shop, reviewed by a human moderator, would become one new node per confirmed shop:
amenity=vending_machine + vending=bottle_return (the wiki’s current method and the iD preset; I saw the recycling_type=reverse_vending_machine discussion and would follow whatever NL prefers)
recycling:cans=yes, recycling:plastic_bottles=yes, and glass or crates only when the visitor confirmed them; never a =no
indoor=yes as @Friendly_Ghost suggested; opening_hours only when they differ from the shop
placed inside the supermarket’s outline (or at its node), because a visitor confirms that there is a machine, not where in the shop it stands
Three things I want your view on before any of this is built:
Position. The node would sit at the shop’s position, not at the machine’s exact spot. Is that acceptable for an indoor machine, or would you want it flagged (a fixme, or something else)?
Duplicates. Friendly_Ghost’s check becomes essential here: before creating, the bot would look for an existing vending=bottle_return within the shop’s outline or a short distance of it, and skip. Is a distance check enough, or would you want every creation held for manual review for the first months?
Import or automated edit? Each node comes from one person’s on-site observation, moderated, one changeset per node. But over a year this could add a few thousand nodes, which starts to look like an import in scale even though there is no dataset behind it. If you would rather this went through the import process, I will do that.
Also settled from this thread, and I will update the wiki page to match:
No automatic removal. A “no machine here” report stays in the app for a mapper to check by hand.
One changeset per correction, so each changeset references one anonymised report and can be reverted alone.
A version conflict re-reads the element once and recomputes; it never re-sends the old copy. A second conflict means the bot leaves the element alone.
Changeset tags: created_by, bot=yes, source=survey, comment, website= the wiki page, and deposit:edit= the anonymised report id.
CasGroenigen, thanks, good to know outdoor machines exist. Another reason indoor= belongs on the node.
Or you could consider being the one that pushes this tag. There is a proper rationale for it. If there is near zero adoption now, it’s unlikely to get going. Unless someone creates a StreetComplete task for it of course.
There are more and more standalone recycling machines that don’t accept crates. Located at train stations and even within private company lunch areas. Those typically only accept cans, no bottles, so you could still implicitly make the assumption if you really want to avoid new tags.
