Proposal: automated updates for deposit-return (statiegeld) locations — Deposit app

The best would be the exact position of the machine, give or take a meter or so. The app should attempt to guide users to place the new machine as accurate as possible. for example by having the picker zoomed in by default, showing own gps location and accuracy ring, having a detailed background map.

If that is not possible a location of the shop poi point would also be ok, in that case do not place it on exact the same location, apply a random small offset. And add a fixme= something like fixme=locatie geschat.

If you are missing tags for example for the bottle crates new tags can be established through community discussion.

recycling:refund_bottle_crates is a great example of not established tagging.
No discussion anywhere, just added by one persoon in: wiki.openstreetmap.org

If an app would use this the percentage of manual additions vs machine additions is wildly shifted.

For example why is this tag prefixed with “refund_” but the others are not?

This depends a bit on the implementation, but generally distance is fine. Do take into account that there can be differences in mapping, For example if a location has two machines next to each other, it could be mapped as two nodes, or as one. Preferable one machine is one node.

1 Like

Thanks both, this is exactly what I needed.

Position. Agreed that exact is better, and I want to be straight about what the first version can do. Indoor GPS in a supermarket is off by tens of metres, so a picker cannot lean on the visitor’s own position; it has to be the visitor placing a pin against the building shape. That picker is planned, but not for the first release. So for the first phase every created node takes @Tjuro’s fallback: the shop’s position with a small random offset and fixme=locatie geschat, and the bot moves the node and drops the fixme as a normal modification once a visitor pins the real spot. One question: is a Dutch fixme fine for NL, or would you rather have English so non-NL tools and mappers read it too?

Crates. Fair point from both of you, and I read Tjuro’s question about the refund_ prefix the same way. I will not have the bot write any crates key on the strength of a wiki line nobody discussed. Instead I will open a short tagging discussion proposing a key for bottle crates, with recycling:crates as my suggestion because it matches recycling:cans and recycling:glass_bottles, and link it here. Until that discussion concludes, crates stay in the app only. If it concludes, the app would indeed be the main source of the tag at first, so I would want the NL community to be fine with that before the bot writes it.

Standalone machines. @Kin_Sapalot, good point about stations and company canteens. The app never assumes materials for a machine a visitor confirmed: it only writes what the visitor selected, so a cans-only machine stays cans-only. Creating a node for a machine that is not at a shop OSM already maps is a further step (there is nothing to attach it to), and I would bring that here separately if it comes up.

Duplicates. Distance check it is: no creation when a vending=bottle_return already exists within the shop’s outline or a short distance from it. One machine, one node is the goal. The bot creates one node per confirmed shop; a second machine next to it would only be added once the position step exists and a visitor pins it separately.

Still open from my previous post: whether you would want this to follow the import process given the scale. I will keep the creation part out of the pilot until that is answered.

Eugen

I would opt for amenity=recycling + recycling_type=reverse_vending_machine

I know there are more proponents fot it but no clear idea if that is a “what NL prefers”.

Can you clarify your intention? (or maybe I missed it before).
I assumed you would be making (new) POIs inside the shops. Similar to how ATMs are most often mapped.

Don’t think I’m the only one:

Whether there are 1, 2 or more machines is actually useful information.

Is amenity=recycling + recycling_type=deposit_refund not a beter option because it describes exactly what happens: for returning your recycle-able item you receive money in return…
This option is discussed in OSM-NL here (scroll down for more crystallized solution options).

In my supermarket there are two machines, one with and one without crates. If i would map that i would map it using two nodes.

What are your plans for handeling multiple machines at one location. How will users select the correct machine to edit or report?

Especially given you do not attempt to place the machine correctly at first.

Also note that you will probably want to group machines bases on distance in your app. Then you can list all the locations, instead of a list of machines.

That discussion is for a statiegeldwinkel, i.e. het pand.

amenity=recycling + recycling_type=reverse_vending_machine (or amenity=vending_machine + vending=bottle_return) is for a machine that can be in a supermarket or statiegeldwinkel.

1 Like

Guys, I have an emergency situation. So I will reply with a huge delay now. Sorry!

1 Like

Back, and sorry for the silence. Answering the four things that came up, and then where this leaves the plan with the two weeks about up.

1. What I intend to create (@Kin_Sapalot, you did not miss it, I said it badly). Yes: new POIs inside the shop, the way ATMs are mapped, one node per machine. My “further step” remark was only about a standalone machine at a station or in a canteen, where there is no shop to attach it to. Supermarket machines are the whole point.

2. Which tag. I read the statiegeldwinkel thread that Dillen_GJ linked, and I take emvee’s point that it is about the facility (the shop or building) while this thread is about the machine. For the machine there are two taggings in use: amenity=vending_machine + vending=bottle_return (about 4000 worldwide, the wiki’s current method and the iD preset) and amenity=recycling + recycling_type=reverse_vending_machine (about 2500, most of them from one import). I do not want the app to be the thing that decides this for NL. So: the bot writes exactly one of the two, whichever this community settles on, and switching the tag for new nodes is a one-line change on my side. If there is no NL decision by the time creation starts, I would default to vending=bottle_return because it is what the wiki and iD currently do, and retag the bot’s own nodes later if NL decides otherwise. If someone would rather see that decided first, I will wait, and creation stays out of the pilot until then.

3. Several machines at one shop (@Tjuro, and Kin_Sapalot’s point that the count is useful). Honest answer: today the app lists one entry per OSM element and does not know that two machine nodes belong to the same shop, so your supermarket with two machines would show as two entries on top of each other. That has to change before the bot creates anything, and it is the same work whether the nodes come from the bot or from you: the app groups machines by the shop they are in (inside the outline, or within a short distance) and shows one location with its machines listed, so a report or an edit is filed against the machine the visitor picks, “the one with crates”. For creation the first version stays one node per confirmed shop; a second machine gets added once the placement step exists and a visitor can put it somewhere. One node per machine is the goal, and I will not create a node where one already exists within the shop.

4. Position, still as agreed with Tjuro: shop position with a small offset and a fixme for the first phase, exact placement later.

Where this leaves the plan. Settled here: no removals, one changeset per correction, material tags only on machine nodes and never on a shop, indoor=yes on created nodes, a duplicate check before any creation. Open: the machine tag (above), the crates key (I will open the tagging discussion I promised once the machine tag is clear, since the answer depends on it), and whether creation at this scale should follow the import process, which nobody has objected to yet but nobody has confirmed either. So the pilot I will ask for, when the bot account exists, is modifications of existing elements only: opening hours and material tags on machines that are already mapped, sandbox first, then a small hand-reviewed live batch announced here. Creation comes back to this thread as its own step once the tag and grouping questions are answered.

Eugen

2 Likes

On Which tag I see your point and I like the NL community to make a decision so I propose to make a poll with two questions:

Wat te gebruiken voor statiegeldautomaten:

  • amenity=vending_machine + vending=bottle_return
  • amenity=recycling + recycling_type=reverse_vending_machine

Wat te gebruiken voor statiegeldwinkels

  • shop=deposit_refund
  • amenity=recycling + recycling_type=deposit_return_point

Iemand tegen?

Ook graag feedback als je nog meer opties hebt dan de bovengenoemde opties.