Enable replacement of a shop by a parcel locker or vending machine

[rhhsm]

Use case
I noticed several cases where a space formerly occupied by a small shop was used to house one or more parcel lockers or vending machines. This is a growing trend here in Sofia, but I've also seen such converted shop spaces on holiday in Italy. However, in SC, shops can only be replaced by other "places" while vending machines and parcel lockers can only be added through the "things" overlay. The workaround I use now is to add the machines in the "things" overlay and leave a note that the shop node can be deleted. Back home I often cut-paste the machine tags to the former shop node to preserve its history, and delete the machine node that I created in SC example.

Proposed Solution

1. Redefine parcel lockers and vending machines as "services" that belong in the "places" list (i.e. move them from "things" to "places", as suggested here Where to draw the line what appears in shop overlay and what not? #5152 (comment)
2. Make parcel lockers and vending machines available as "shops" in addition to being available as "places".

[paulklie]

I noticed several cases where a space formerly occupied by a small shop was used to house one or more parcel lockers or vending machines.

Hmm, I think the correct solution here would be to actually replace the shop with a shop = vending_machine.

However, since this tag is not supported by id-tagging-schema, (and unlikely to be added due to how rare it is) you currently cannot add it via SC.

[mnalis]

TL;DR: issue happens rare enough that leaving a note is probably just fine, and:

• possible solutions seem hacky/confusing or their prerequisites not likely to happen soon ( e.g. shop=vending_machine landing in id-tagging-schema)
• it would be wrong re-tagging if that ex-shop=* was on an area (e.g. building=retail) and not on single node

---

However, since this tag is not supported by id-tagging-schema, (and unlikely to be added due to how rare it is) you currently cannot add it via SC.

Yes, the threshold for inclusion in id-tagging-schema seems to about 1000 uses, so shop=vending_machine needs about a 10-fold increase to be eligible; and current growth graph does not make that likely (unless it happens to grow exponentially, e.g. if someone invest time to promote / map them).

1. Redefine parcel lockers and vending machines as "services" that belong in the "places" list (i.e. move them from "things" to "places"

Uh, I don't like that. So parking machines, ATMs, luggage lockers, photo booths, sanitary dump stations, public telephones, binoculars and many other "Things" that are likely to have fee=yes (IOW, are "services") should/would become "Places" too?

And there are many others which don't have fee, but would properly fit under services, e.g. survellience cameras, water taps, bbqs, hunting stands, garbage dumpsters, device charging stations etc.
At that point IMHO, we might we well get rid of distinction and group both Things and Places under single "POI" group.
(but that is obviously unwanted, as it makes adding POIs too crowded)

2. Make parcel lockers and vending machines available as "shops" in addition to being available as "places".

Somewhat better, but I'm still not a big fan of that either as it feels hacky and introduces confusion (some things are shown in both Things and replacement shops, but others aren't)...

---

Since it does not seem to happen all that often:

I noticed several cases

probably leaving a Note is OK "solution"¹ (and I'd guess preferred to other solutions, such as ugly hacks injecting extra values like shop=vending_machine in id-tagging-schema so they could be used as replacement shop).

Especially because one can never fully fix it, as there are many other things that could have replaced that shop there, but which are not present in SC "Places" (or even in id-tagging-schema at all).

Also, importantly note that if the ex-shop=* was tagged on an area (e.g. building=retail), it would be simply incorrect to re-tag that whole area to amenity=parcel_locker (as parcel locker itself does not take all that area - you wouldn't be able to enter the building otherwise!) or amenity=vending_machine (which is not even specified can be used on an area), so retagging to those values would have to be limited to just nodes, not areas, which introduces much more complexity for a little gain.

Footnotes

1. or of course, if one uses SCEE, they can just use raw tags functionality to change it immediately on the ground ↩

[westnordost]

I agree with @mnalis

And thanks for all those TLDRs, also in all your other posts, I think it is really helpful to have a summary first 👍

[rhhsm]

I wish I had time to add some counter-arguments before this issue was closed...

it would be wrong re-tagging if that ex-shop=* was on an area (e.g. building=retail) and not on single node

The situations where my proposal could be useful are always on very small shops that are unlikely to be mapped as areas. This https://maps.app.goo.gl/r1HgdVpGxa2mMPTTA is an example where there is place for only 2 vending machines. The largest I've seen had 2 parcel lockers and 3 vending machines in it. It should be implemented only for shops mapped as nodes.

Hmm, I think the correct solution here would be to actually replace the shop with a shop = vending_machine.

I prefer to add the vending machines and parcel lockers themselves, as the shop tag is rare.

Uh, I don't like that.

Me too, I mentioned it as a possibility because it has been proposed. I think it is natural to expect to find these machines among "Things" because they are of similar size as other "Things".

introduces confusion

I don't think so; the line between what are "Places" and what are "Things" is fuzzy, and it is a practical benefit that some items that are near the line can be found in both. User will only have a problem if they can't find an item, not if they can find them in two instead of one place. It also helps to locate new nodes correctly if items from both "Places" and "Things" (and entrances #5497) can be seen in the same layer. It happens quite often when I want to add a new "Thing", I place the crosshair at the right position relative to shops in the "places" overlay and then switch to the "Things" overlay to add the Thing. At least for vending machines and parcel lockers, I wouldn't have to do this any more.

probably leaving a Note is OK "solution"

I'm afraid it's hard to write a note such that someone solving the note will realise that the obsolete shop node should not be deleted, but the tags of one of the newly added machines should be copied to it (to keep the node's history), and the new machine node from which the tags were copied should then be deleted.

I think the best choice between:

1. Adding parcel lockers and vending machines to the list of "Places" that can be added in the Places overlay, and
2. Doing nothing and hope that notes can solve the issue

is choice 1.: giving up the rigid principle that some node to be added cannot be listed both in the Places and Things overlay will not lead to confusion and has practical benefits. Choice 2. has a high risk of leading to loss of history of shop nodes.

[mnalis]

TL;DR: (I still see more issues and new problems then the ones that would be solved. The rest of this is post is detailing why there are still more problems, and what possible workaround users might use, e.g. leaving notes or opening in Every Door).

---

I wish I had time to add some counter-arguments before this issue was closed...

Yeah, it is unfortunate. I too would sometimes prefer if at least a few days (or a week) were allowed to pass before closing the issues. But then, GitHub does not provide good interface for tracking that, so I get it why they get closed early...

On the other hand, "closed" issue status it is not a huge deal -- if you provide compelling counterarguments which significantly outweigh the problems, I'm sure it can be reopened (but IMHO I don't think it is the case here).

introduces confusion

I don't think so; the line between what are "Places" and what are "Things" is fuzzy, and it is a practical benefit that some items that are near the line can be found in both. User will only have a problem if they can't find an item, not if they can find them in

Well, I still think it it would be confusing for me.

EveryDoor for example allows to add "Things" in "Places mode", and to add "Places" in "Things mode" (names are different there, but I'm using the SC terms for clarity), and I find it very confusing and disorienting, as I regularly fail to notice that "wrong mode - check for duplicates" warning in the corner of the screen.
And that is with EveryDoor having consistency working for it (i.e. you can add any Thing in "Places mode", not just some of them, which would be much more confusing).

It also helps to locate new nodes correctly if items from both "Places" and "Things" (and entrances #5497) can be seen in the same layer. It happens quite often when I want to add a new "Thing", I place the crosshair at the right position relative to shops in the "places" overlay

Well, if you are proposing merging of Things and Places, that should be a separate issue... While I certainly see some benefits of it (which you note), I also happen to think that the disadvantages are more significant (e.g. unbearable overcrowding of icons when one cares only about "Places" - like I guess majority of SC users do. Us micromappers are a minority...)

The situations where my proposal could be useful are always on very small shops that are unlikely to be mapped as areas

Well, it might be dependent on the area. Over here for example, even small 3x3m kiosks are quite often tagged as building=kiosk + shop=kiosk polygon.

it should be implemented only for shops mapped as nodes.

Yeah, I agree it should, otherwise we would create invalid data on those areas...

Note however that this seemingly small detail would increase code complexity drastically. SC does not have a support for such filtering (i.e. return one list if element type is node but different list if the element type is (closed) way (area) -- we always return same fixed list, regardless of what the original element was.

So extra support for that should first be written, and database of tag properties established (i.e. for each tag define on what type of element it may be offered, and/or with what tags it is incompatible¹), before your suggested change would even become possible to implement. And then such list would need to maintained each time there is id-tagging-schema update.

probably leaving a Note is OK "solution"

I'm afraid it's hard to write a note such that someone solving the note will realise that the obsolete shop node should not be deleted, but the tags of one of the newly added machines should be copied to it (to keep the node's history), and the new machine node from which the tags were copied should then be deleted.

No, I didn't mean your current workaround of adding Thing + note (or remembering), but just leaving a note (e.g. "This shop is replaced by snacks vending machine", preferably accompanied with picture). And then (ideally) solving your own notes when you get home, by replacing tags on existing shop node. That would also take care of your history problem:

Choice 2. has a high risk of leading to loss of history of shop nodes.

... as no history would be lost in that case.

However, note that if you're replacing an area-based shop with vending machine node, or if you 're replacing one node-based shop with multiple node-based vending machines (quite likely, some history will be lost in any case, as it is not technically possible to avoid it.

But history loss is not such a big issue here anyway IMHO - those vending machines are not really a new version of that shop; they just tend to occupy the part of space where that shop was, so it is questionable if they even should share history (e.g. think what if shop was replaced with garbage dumpster at that place instead?)

• Another alternative that one might use in StreetComplete is long click - "open location in another app" - EveryDoor (or Vespucci) and then replace the node tags with that.

• And my favourite (as I'm personally most likely to be using SCEE already), I would probably just use SCEE raw tag editor to replace tags. Especially as adding vending key will also offer me a dropdown list of more popular values.

Footnotes

1. e.g. defining that amenity=vending_machine is conflicting with building=*, but that e.g. shop=* and amenity=restaurant aren't. ↩

[rhhsm]

Note however that this seemingly small detail would increase code complexity drastically.

That is something I cannot judge. I thought that to code that IF user selects area in Places overlay THEN don't offer vending machines and parcel lockers as replacement options would be easy; if it isn't, then what I propose is not worth the effort.