Proposal talk:Amenity=parcel locker

Limiting to nodes

Resolved: Areas will be allowed

Thanks for the good proposal!

You wrote:

"Areas > No* ... * some parcel lockers can be quite large but mapping them as areas won't help and it will just make it more difficult for data consumers since they would need to search both nodes and ways to get elements they are looking for. If the packstation constitutes a barrier of some kind the "barrier" (linking polish article about the biggest one in Poland) should be tagged separately using other tags. "

I would like to suggest extending this to areas as well. I'm sure that many mappers will map this as an area, regardless of this proposal. The dimensions of the facilities is large enough for that. This is also done with objects of a similar size, such as shelters at bus stops.

Other POIs are also often mapped as an area, e.g. if they occupy an entire building. It should therefore be the standard that data consumers also analyze areas. It's not difficult to program either. We shouldn't limit ourselves here just because some data consumers don't bother to properly evaluate the data (no tagging for the renderer).

--Jo (talk) 20:37, 3 November 2021 (UTC)

I agree with Jo. I can't really see the problem for apps and people WILL want to map parcel lockers as areas just like they do with bike rentals.

--Rmikke (talk) 20:42, 3 November 2021 (UTC)

I'd suggest that for very long units, such as the Polish one mentioned, possibly map them as a way, so that they appear similar to a stand-alone fence. I don't think area would work as they're only very shallow (~1m). Alternatively, only use a node, but include width=* to show that it unit is 3 / 10 / 30m wide? --Fizzie41 (talk) 22:07, 3 November 2021 (UTC)

A node with width=* would make a circle in my opinion.

That it is possible to map parcel stations as an area is shown by the examples where it is already done, for example here: way/894387324.

I think it should be left to the mapper to decide when to map objects as area, way or node.

As the proposal is now, the 2.5% of the parcel stations mapped as an area should not be tagged with this tag. I don't see an important reason for this restriction.

--Jo (talk) 23:10, 3 November 2021 (UTC)

I appreciate your comments but I don't see much reason to allow/encourage mapping these as areas and unless there is consensus that it's needed I believe it's easier to have these as nodes only.

> I'm sure that many mappers will map this as an area, regardless of this proposal

Sure people map stuff in a way they personally like all the time but wiki should be clear about what is encouraged/discouraged.

Mappers may want to map this as an area because: 1. They want to provide more details/data 2. They want it to render better 3. They like "filling the map" (not sure how to phrase that in a better way).

Ad. 1 the information provided would be of marginal utility. As you mentioned only like 2% of existing objects have been mapped as areas and it's unlikely that this percentage would change significantly with more objects mapped and if only such a small number of objects would be areas this information would be difficult to rely on for anything other than render. These machines are usually the size of about two benches so majority of them are small enough that it doesn't make sense to map them as areas.

Ad. 2 We would need to specify how they should render in that case. From what I have seen about aforementioned bike rental stations they don't render in any special way when mapped as area i.e. they only have an icon, no borders around area so it's not visible. Specifying these additional rules for handling areas seems like additional work that is not worth it considering that only a few % of the objects would be areas anyway.

Ad. 3 Well that one I got nothing but I don't think it's super important

Prohibiting mapping this as an area wouldn't make things easier for data consumers, it would make it harder by introducing an exceptional case. Most "thing"-type objects (businesses, cities, etc.) can be mapped as either an area or a point; point-only and line-only tagging tends to be reserved for "conceptual" objects such as a river flowline or a survey point. --Carnildo (talk) 18:47, 15 November 2021 (UTC)

+1, data consumers may relatively easily produce centroid (available, for example in Overpass API). Though I would strongly encourage it Mateusz Konieczny (talk) 23:55, 16 November 2021 (UTC)

Apparently half of my response was cut because I used emoji in text which corrupts osm wiki data... I don't feel like writing it again but here's an example of guy making 187 rules that classify whether closed way is a polygon, a line, or both at the same time: https://www.youtube.com/watch?v=rbxabz22ni4&t=1016s and he it still failed to cliassify 4 000 000 ways so to address Jo (talk) 's point: no it is not easy to parse osm areas, the model is just deficient.

Interest in allowing mapping these features as areas is big enough that I will change the proposal to accommodate that.--Tomczk (talk) 00:00, 18 November 2021 (UTC)

I have a different, related case. There are some put in a dedicated room or shop space, perhaps even small sheds and buildings. This should be allowed. The same situation occurs in amenity=atm and amenity=vending_machine, documented as no areas already. This was raised in Talk:Tag:amenity=atm#ATM_Buildings, as early as 2012; and Talk:Tag:amenity=vending_machine#Vending_machine_as_area (although this is for big onesm not about vending machine corners). ----- Kovposch (talk) 08:58, 10 November 2021 (UTC)

Plural?

Resolved: Main tag changed to parcel_machine

Thanks for your initiative. As usually amenity=* tag has its value for a single object, shoudn't this one be named "amenity=parcel_locker"? Does "lockers" word here refer to many small "shelves" in one parcel "cage"? If "locker" means one big cage, it should be "amenity=parcel_locker" Tomasz W (talk) 07:45, 4 November 2021 (UTC)

I agree it should be "amenity=parcel_locker" I completely agree with the rest of the proposal. Thanks Tomek for this! --Cristoffs (talk) 15:33, 4 November 2021 (UTC)

In the discussion of the previous proposal it was mentioned that:

> One locker is just one compartment, therefore the plural parcel lockers should be fine for the whole facility.

English is not my native language so I'm not sure which is more correct.

--Tomczk (talk) 14:46, 7 November 2021 (UTC)

Changed plural to singular as per request --Tomczk (talk) 18:50, 21 November 2021 (UTC)

Why "parcel_locker" and not "parcel_lockers"? "Parcel" is a countable noun in English and there are many lockers in one machine. Could you please explain why and provide sources in English where "locker" is used for such machine? maro21 23:12, 1 December 2021 (UTC)

vending_machine seems OK

Resolved: Not much to address here. Vote will decide if current tagging scheme or proposed one is preferred.

Personally I am fine with amenity=vending_machine here, after all it is automatic machine dispensing/receiving items, in some cases selling service. But I also see why someone would be unhappy about tagging so I am not opposed. But changing tagging scheme has some costs. Mateusz Konieczny (talk) 12:45, 4 November 2021 (UTC)

Just a note: this is not amenity=automate or just amenity=machine, which would be fine. Vending is implied in the name, which is simply not true in this case - see https://en.wikipedia.org/wiki/Vending_machine - it's much closer to amenity=letter_box and amenity=post_box, but also different. --Kocio (talk) 23:03, 4 November 2021 (UTC)

I interpret it as selling service, not product Mateusz Konieczny (talk) 17:00, 5 November 2021 (UTC)

I believe that's stretching the definition too much. The same would be then true for a post box - you put a stamp (you pay for service this way) and your message is being collected here as part of the sending service. --Kocio (talk) 17:09, 5 November 2021 (UTC)

No, vending machine is a way to sale the specific kind of good. but those parcel lockers are focus on safekeep user's parcel，it offer the keep service. --快乐的老鼠宝宝 (talk) 12:27, 14 November 2021 (UTC)

"amenity=vending_machine; vending=parcel_pickup" already exists for this concept - this proposal doesn't add anything to the meaning of that. Approving a duplicate would just cause unnecessary confusion. SomeoneElse (talk) 17:39, 14 November 2021 (UTC)

To me, having a cleanly defined tag seems like an improvement over stretching the definition of "vending machine". Also, vending=parcel_pickup;parcel_mail_in (or the other way around, or with additional spaces in the value) is a pretty awkward tag. --Tordanik 18:59, 14 November 2021 (UTC)

+1. It's not unusual that sometimes we're stretching the literal meanings of tags, e.g. landuse=forest or the contact=*-prefix. From such a literal interpretation of "vending" as presented in the proposal it follows that fee=no would be incompatible with vending=*, meaning that we would also need a new classifying tag for e.g. free excrement bag dispensers, bottle return machines, …. So I think that at least this point is not much of a convincing argument. Additionally, tagging parcel lockers as their own amenity=*-class would also mean that they are probably excluded by most general purpose maps that simply filter by amenity=vending_machine.

PS: I'm surprised that the semantic beauty of tags has become a criterion for inclusion into OSM-Carto.--Nw520 (talk) 02:13, 15 November 2021 (UTC)

If the proposal passes OSM-Carto will be happy and will render the features. If the proposal fails it will show that community considers current tagging scheme as valid and we can ask them to render these feature with current scheme. Fine with me either way, voting seems to be the best way to resolve this. --Tomczk (talk) 00:27, 18 November 2021 (UTC)

Clarify groupings

Resolved: Answered question

Sometimes there are multiple machines next to each other - either in one row or separated. I would explicitly indicate that in such case one object should be created, not one for each locker or for each interface Mateusz Konieczny (talk) 17:58, 4 November 2021 (UTC)

But you'd need to show that there is a DHL locker, + FedEx, UPS, Couriers Please etc, all together in the one spot? --Fizzie41 (talk) 22:24, 4 November 2021 (UTC)

Multiple machines from one company? Or different companies? If they are different machines with different ref=*, they should be mapped separately. maro21 22:31, 4 November 2021 (UTC)

OK, in case of a different companies I would tag them separately. In case of multiple refs from one company I would use ref=1616;1617 Mateusz Konieczny (talk) 17:05, 5 November 2021 (UTC)

Other aspect of grouping: I'm not sure, but I think I remember parcel lockers with integrated letter box, maybe it could be a good idea to have the possibility to combine this in one object. This would imply something like parcel_locker=yes (which has other disadvantages...). --Segubi (talk) 19:04, 4 November 2021 (UTC)

I would map them: one object per one operator/brand + id (ref); if id (ref) is unknown then one object per one operator/brand; if that is unknown then add one feature and let other mappers improve that in the future. If there is integrated letter box then either it is part of the machine and attribute for sending letters should used or it is separate letterbox/postbox and separate feature should be used. --Tomczk (talk) 00:20, 18 November 2021 (UTC)

Where's type?

Resolved: Addressed question about type

Was quite unhappy with current tagging, jsut a single thing:

Current scheme has type=circular/cabinet/parcel_box/station, which is kinda just the German types but still was kind of useful.

I assume that, unless the proposal decides to address it, we could continue to use these existing tags. (Even though it would be better to have a different key than type=*, which is normally used for relations.) --Tordanik 15:58, 10 November 2021 (UTC)

If undecided, could move to generic/unspecified parcel_lockers=* first.

Now I realize a question: Should it be singular amenity=parcel_locker or plural amenity=parcel_lockers???

---- Kovposch (talk) 13:05, 14 November 2021 (UTC)

Yeah I think it would be fine to keep using those. If you have photos for each type so it would be properly documented you can add this to the proposal now otherwise I think you can add it later to the wiki pages. --Tomczk (talk) 18:41, 21 November 2021 (UTC)

"Circular", more of a geometry, doesn't quite fit among other 3. Will need to more detailed grouping. ---- Kovposch (talk) 13:05, 14 November 2021 (UTC)

Receiving/sending in Post offices

Resolved: Changed parcel_receiving to parcel_pickup

Unresolved: Kovposch (talk) 01:02, 22 November 2021 (UTC)

Resolved: changed parcel/letter_receiving/sending to _to/_from as requested--Tomczk (talk) 23:00, 22 November 2021 (UTC)

I'm overall in favour of this proposal, with one note:
in case we're sticking with your parcel_receiving, parcel_sending, letter_receiving and letter_sending tags I think they should also apply to amenity=post_office and possibly other post-related amenities. Those are probably in demand, as seen in post_office's wiki page, that suggests using similar supplementary tags:

post_office:parcel_send_in=yes
post_office:parcel_mail_in=yes
post_office:parcel_pickup=yes

according to taginfo post_office:parcel_mail_in=yes was used 131 times, exclusively in 2021 (no instances of the other 2 though). This tagging scheme should probably be discouraged in favour of new tags in order to avoid multiple standards --Mordechai23 (talk) 13:26, 9 November 2021 (UTC)

No, my opinion is the opposite. We should standardize with amenity=post_office and post_office=*. Guess @Tomczk: may not know about post_office:*=* already "approved" in Proposed_features/shop_as_post-partner.

• parcel_receiving=* --> parcel_to=*
• parcel_sending=* --> parcel_from=*
• letter_receiving=* --> letter_to=*
• letter_sending=* --> letter_from=*

Again, I guess someone confused vending:*=* and post_office:*=* in the post_office:parcel_send_in=yes + post_office:parcel_mail_in=yes example. Edited.

---- Kovposch (talk) 08:37, 10 November 2021 (UTC)

Didn't know about this, but after reading post_office=* I support what @Kovposch: says. In addition I think post_office:oversized_item=* could also apply --Mordechai23 (talk) 16:31, 10 November 2021 (UTC)

+1. Should those keys be prefixed too? -Nw520 (talk) 02:25, 15 November 2021 (UTC)

I changed parcel_receiving to parcel_pickup since it's better but other tags with "_to" and "_from" I find pretty confusing and geared specifically toward post office instead of these machines so I don't think it would be good to use them in favour of simpler parcel_sending. --Tomczk (talk) 19:31, 21 November 2021 (UTC)

You misunderstood *_pickup=*. It refers to "pickup" of missed deliveries, not this. It's bad to have differing meanings.

Why are they "geared specifically toward post office"? They may not the best, but a standard system is better than a different set in every other feature. *_to=* & *_from=* are shorter than *_receiving=* (easy typo spelling) and *_sending=*.

If you insist on not using them, prefix with parcel_lockers:*=*.

---- Kovposch (talk) 01:02, 22 November 2021 (UTC)

Changed tags to parcel_to/from, letter_to/from as requested above. --Tomczk (talk) 23:00, 22 November 2021 (UTC)

In Germany, the third option of parcel_pickup can be also valid for lockers.

I am still do not like "from" and "to" --Skyper (talk) 17:20, 27 November 2021 (UTC)

redundant parcel_receiving tag?

Resolved: Changed description to make parcel_receiving/pickup assumed to be "yes"

The parcel_receiving tag makes no sense in my opinion. Are there any machines from which one cannot receive a parcel, but only send it? Only then it would be useful. IMO you can pick up a parcel from every machine, but probably not in every machine you can send it. That's why I'm against adding parcel_receiving=yes, if that one is already contained in the amenity=parcel_lockers tag. Unless someone can convince me how amenity=parcel_lockers will differ from amenity=parcel_lockers + parcel_receiving=yes. It's like if we added an extra can_you_order_meal_here=yes tag to amenity=restaurant every time. maro21 17:00, 9 November 2021 (UTC)

Paketbox

At least in Germany there used to be so called Paketboxen which could be used (only) for handing in already-stamped parcels. (However, I doubt that there are still many around though I do think that having a possibility to tag them is desirable). --Nw520 (talk) 01:49, 15 November 2021 (UTC)

Also cf. Proposed features/Parcel lockers and parcel postbox#Parcel postbox. --Nw520 (talk) 02:18, 15 November 2021 (UTC)

But this is amenity=post_box or amenity=parcel_box. This isn't a locker. maro21 16:44, 17 November 2021 (UTC)

I doubt that such boxes can be considered amenity=post_box and with currently only 10 instances amenity=parcel_box doesn't seem to be an established tag. Currently such parcel boxes can be tagged as amenity=vending_machine+vending=parcel_mail_in. If this combination becomes deprecated and parcel postboxes are not considered parcel lockers, we would need a new tag for them. --Nw520 (talk) 18:18, 19 November 2021 (UTC)

Changed requirement to provide parcel_receiving/pickup=yes. --Tomczk (talk) 19:31, 21 November 2021 (UTC)

That's why amenity=parcel_postbox was proposed in the previous proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/Parcel_lockers_and_parcel_postbox maro21 14:53, 5 December 2021 (UTC)

Direction

Resolved: addressed proposal of adding additional attribute with direction

Thanks for creating this proposal! I would suggest mentioning the possibility of adding direction=* to define where the front of the facility is facing. --Tordanik 15:57, 10 November 2021 (UTC)

So what is the direction=* value for this machine?:) maro21 16:47, 17 November 2021 (UTC)

@maro21 direction of panel ;) @tordanik Thank you for your input but to be honest I'm not sure it would help. If there is a fence or other barrier that restricts access to machine it should be mapped as separate object. These machines are not large enough that navigating to the front of them would be a problem other than aforementioned fences so I don't think adding this as attribute would be useful. --Tomczk (talk) 00:11, 18 November 2021 (UTC)

I agree that it's not necessary for navigation, but it is helpful for other applications. For example, I'm using direction=* for correct rotation of the model in 3D rendering. --Tordanik 20:52, 9 December 2021 (UTC)

Is this only can for post usage?

Resolved: questions answered

At first, amenity=parcel_lockers is a good feature, some brand had already built their lockers network in China and we are confused with the tag. (Before we usually use post_box, now we can transfer to this tag)

But sometimes, some supermarkets, office building, will offer free or low charge personal stuff storage lockers, will they can use this new tag?

And, how we separate this new tag with "amenity=vending_machine+vending=parcel_pickup"?

--快乐的老鼠宝宝 (talk) 12:34, 14 November 2021 (UTC)

No, use amenity=locker. ---- Kovposch (talk) 12:59, 14 November 2021 (UTC)

According to Proposed_features/Locker#Affected, should iD remove the "amenity=vending_machine+vending=parcel_pickup" preset? --快乐的老鼠宝宝 (talk) 13:07, 14 November 2021 (UTC)

amenity=locker would be best choice for those as mentioned. Yes we would need to change iD preset once the proposal passes. --Tomczk (talk) 00:13, 18 November 2021 (UTC)

"to" and "from"

Resolved: Changed tags to the same as values of current vending tag.

The meaning of these tags isn't clear for me because here we have prepostions without a noun phrase. Prepositions are not independent parts of speech and don't occur separately. Previous names "parcel_pickup" was better but still ambigous. It isn't clear if the machine receives a parcel from me, or I receive a parcel from the machine. maro21 16:09, 24 November 2021 (UTC)

I find them unintuitive too but they passed the vote so... I am open to whatever you and @Kovposch: find as acceptable solution. --Tomczk (talk) 23:56, 24 November 2021 (UTC)

+1, for more descriptive keys. In #Receiving.2Fsending_in_Post_offices sending and receiving are mentioned. --Skyper (talk) 17:15, 27 November 2021 (UTC)

My suggestion is to have only parcel_sending=* or parcel_mail_in=* which is unambigous - I, the user of the machine, send the parcel so it won't be confused like with receiving (I can receive or the machine can do it) because the parcels in the machine are already sent. And drop the tag about "receiving" on the assumption that the amenity=parcel_locker[s] tag itself says that this object is primarily for taking packages by people. If one can't take packages from it, then it's not amenity=parcel_locker[s]. maro21 19:36, 27 November 2021 (UTC)

This proposal aims to deprecate vending=parcel_mail_in. What should be used if amenity=parcel_locker is not the correct tag? If sending and receiving does not fit we need to find better words as "to" and "from" suffer the same problem. My goal would be a subtag which fits all amenity=*/shop=* offering services of receiving or sending letters and parcels. --Skyper (talk) 20:51, 27 November 2021 (UTC)

Yes, there is post_office=* + post_office:*=* already. I only doubt the usefulness of changing a recently "approved" tagging system. If you really want to, you could ask for using a different set of parcel_lockers:*=* (as I said), but then it's not cross-standardized. ---- Kovposch (talk) 21:05, 27 November 2021 (UTC)

Sorry, I missed the refinement of post office tags. While I still do not like it, I understand that using the similar/identical keys is appreciated. So I can accept "to", "from" and "pickup". The question what to do with machines with only "mail_in" remains. --Skyper (talk)

+1 for more descriptive keys "parcel_from=yes" is completely unclear is it referring to parcel from packstation to user or parcel from user to packstation Mateusz Konieczny (talk) 07:03, 28 November 2021 (UTC)

Since the discussion died down and there is no consensus what to change these tags to I'm marking it as resolved and will launch vote in the next few days. --Tomczk (talk) 23:15, 30 November 2021 (UTC)

I would not consider a few days without comment the end of a discussion. Some people might not have time for a few days, please, be a bit more patient. Thanks. --Skyper (talk) 14:48, 2 December 2021 (UTC)

I prefer current tagging with a bit questionable vending and clear parcel_pickup / parcel_mail_in over this unclear tags :( Mateusz Konieczny (talk) 12:53, 1 December 2021 (UTC)

No consensus? I can't see anyone who liked "to" and "from" variants.

The keys you proposed: Key:parcel_to, Key:parcel_from, Key:letter_to, Key:letter_from are not understandable. I suggested to have one additional key instead of these ones - parcel_sending or parcel_mail_in for machines where I can post a parcel. maro21 23:05, 1 December 2021 (UTC)

+1, at the current form, I see not enough benefit in this proposal. I am fine in moving this out of vending_machine, though I see no need. From the proposal, I would expect an upgrade in keys' and values' names and their description but in my eyes this is not the case, atm --Skyper (talk) 14:48, 2 December 2021 (UTC)

Only one tag for parcel_* and letter_*

Resolved: Values separated by semicolon should be avoided

Are there more values planned for parcel_* and letter_* than "yes" and "no"?
Why do we need that many keys instead of letter=receiving;sending;pickup --Skyper (talk) 17:27, 27 November 2021 (UTC)

This doesn't work as well, same in other tags. You could yet ask why it wasn't parcel:pickup=* to separate parcel:*=* and *:pickup=* at the time. This part didn't receive much attention. I can I haven't looked into it closely either. ---- Kovposch (talk) 20:53, 27 November 2021 (UTC)

Values separated by semicolon is bad and should be avoided. You will have permutations of all possible values in all possible orders. It makes it more difficult to parse. --Tomczk (talk) 22:38, 28 November 2021 (UTC)

Multiple values is a common practice is OSM. Please, link to the page where it says, that this should be avoided. If some software has problem with multiple values and permutation, fix the software. --Skyper (talk) 13:17, 29 November 2021 (UTC)

It's only common for very specific tags like opening hours or refs and a few others. https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator#When_NOT_to_use in the section describing how various applications deal with those kinds of values you'll see that support for them is implemented mostly these specific scenarios and likely won't play nicely with just putting them in random other tags. In most cases it will be simpler for everyone to split the value into separate tags creating something resembling one-hot encoding. --Tomczk (talk) 17:20, 29 November 2021 (UTC)

It is not true, that it is only used for specific tags. I find it in all place like access tags and listings about services e.g. cuisine=* or service=* for shop=car_repair. In fact, the subkeys of post_office=* use semicolon separated values, too, as together with yes and no operators can be listed. --Skyper --Skyper (talk) 15:03, 2 December 2021 (UTC)

How are they handled in most popular OSM software (or more specifically most popular consumers Carto, OpenMapTiles)? I skimmed post_office article and I don't see them using semicolons. They have separate keys for different services etc. using colons to mark namespaces but they are separate tags with yes/no instead of one tag with service1;service2. Anyway... not breaking 1NF unless absolutely necessary is a good idea with current OSM data model (all values are strings). --Tomczk (talk) 23:11, 7 December 2021 (UTC)

Please, carefully reread the mentioned page again. Adding multiple tags with only values "yes" and "no" is completely unneeded as consuming software should have no problem to split at the separating semi-colon. I doubt that Carto will ever support these subtags like motor_vehicle=agricultural;forestry, but, please, proof me wrong. Mean-while I see returns_only and I wonder if some more values are useful. --Skyper (talk) 17:43, 26 December 2021 (UTC)

multiple tags with only values "yes" and "no" are often much nicer in editing (both for mapper and author of editing software) Mateusz Konieczny (talk) 00:26, 27 December 2021 (UTC)

difference between letters and parcels

Resolved: Removed tags dedicated to letters.

What is the difference between a parcel and a letter in the context of this proposal and keys "letter_to", "parcel_to"? maro21 23:09, 1 December 2021 (UTC)

Realy? Are you trolling or what? On the Polish Discord, there was a discussion during Friday meetings about the need to organize the markings of parcel machines. For this the entire thread on the forum. All due to the popularity of this method of parcel delivery, the expansion of services offered in parcel machines and the entry of new companies into the industry (I will not mention construction stores with their own parcel machines). All this makes parcel lockers significantly different from postal boxes. Currently, OSM does not keep up with the trend and the users' needs in this matter. --Cristoffs (talk) 12:01, 5 December 2021 (UTC)

This doesn't answer my question at all. Write on topic, please. My question referred to letter and package in the context of this proposal and keys "parcel_to", "letter_to". maro21 14:25, 5 December 2021 (UTC)

Could you elaborate on the purpose of this question? My guess is you want to merge parcel_to and letter_to into one tag (see section above), but that's only a guess. Rmikke (talk) 16:37, 10 December 2021 (UTC)

These tags are simply not defined. Do you think of "letters" and "packages" in the context that a letter is an envelope with a stamp on it, and a package is a box that doesn't have a stamp on it? And what has this to do with parcel machines? On which parcel machine of which company there is a distinction between letters and parcels? Courier companies do not have such distinction - if you want to send documents in an envelope it is also a parcel. I just want to have a main tag for parcels, and we add a lot of unnecessary additional tags that we don't have to vote on. maro21 19:55, 17 December 2021 (UTC)

OSM wiki is not a legal document and this level of detail is not standard when defining tags in OSM. --Tomczk (talk) 18:01, 12 December 2021 (UTC)

Rename to amenity=parcel_pickup_station

Resolved: Renamed to parcel_machine which was proposed in the discussion below.

I suggest to rename the main tag to amenity=parcel_pickup_station. This is a more general name and can also include machines that are not lockers. Perhaps such ones will be created in the future or already exist (is every machine for picking up parcels a locker?). maro21 14:32, 5 December 2021 (UTC)

Fine with me --Tomczk (talk) 00:35, 7 December 2021 (UTC)

1. "station" may be confused with shops. You want eg amenity=parcel_machine like amenity=vending_machine?
2. You still need parcel_*=lockers for this.

---- Kovposch (talk) 06:15, 7 December 2021 (UTC)

"station" may be confused with shops - Why? We have many tags with "station" in the name which are small amenities: amenity=charging_station, leisure=fitness_station, man_made=monitoring_station, man_made=pumping_station, amenity=bicycle_repair_station, amenity=sanitary_dump_station...

Parcel_machine may be ok, but I'm still curious how is this thing called in English-speaking countries. maro21 22:44, 9 December 2021 (UTC)

2 - why do we "need"? We're going to define the tag "amenity=parcel_pickup_station" (or other tag, however it will be called) as "a machine, usually in a form of lockers, for pick up parcels". maro21 22:50, 9 December 2021 (UTC)

1. man_made=pumping_station is already not "small". Usually it can fit a human inside. Tag:man_made=pumping_station describes it as "a facility including pumps and equipment". To compare, parcel machine is similar scale as a man_made=pump set. amenity=charging_station is not amenity=device_charging_station either. As an area, it can include the entire site, like amenity=fuel.
2. This proposal is about lockers. If you are going to expand it, better include its original purpose. It is not completely certain to assume every machine is a locker, especially when you "include machines that are not lockers". Another problem I initially didn't remember is they can "be used as ordinary lockers", per Proposed_features/amenity=parcel_lockers#Proposal. How do you express ones that can function as a locker?

When you are already defining it be "a machine", why not use amenity=*_machine directly? This resembles amenity=vending_machine. Or at least amenity=parcel_terminal, to not require it to be mechanized.

---- Kovposch (talk) 22:19, 10 December 2021 (UTC)

So is amenity=parcel_machine ok for everyone? Unless there are objections within a day or two I will edit proposal to use that tag. --Tomczk (talk) 18:04, 12 December 2021 (UTC)

Why include "pickup" in value when one can do more than pickup (like sending)? Rmikke (talk) 16:29, 10 December 2021 (UTC)

locker or lockers ?

If the main tag was to be changed back to parcel lockers should it be amenity=parcel_locker or amenity=parcel_lockers ? Asking native speakers: @Rjw62: @MikeCollinson: @JassKurn: --Tomczk (talk) 13:24, 19 December 2021 (UTC)

I'd suggest Parcel Lockers, but I would understand people suggesting the overall object is single entity and should be Parcel Locker. I have seen residential houses installing a single Parcel Locker for delivery of parcels, so using Parcel Lockers for this multiple lockers feature would help distinguish from the individual House Parcel Locker. JassKurn (talk) 19:43, 19 December 2021 (UTC)

amenity=letter_box and amenity=locker are singular. ---- Kovposch (talk) 20:14, 19 December 2021 (UTC)

Retagging

When will happen the mass retagging? I am asking because we have thousands of nodes in Czech republic and we need to sync it up with our import tools.

French community is going to do it for France: https://wiki.openstreetmap.org/wiki/Mechanical_Edits/overflorian-mass-edits/deprecate_vending%3Dparcel_pickup_in_France

In Poland it is currently discussed but will probably happen once the discussion is settled: https://forum.openstreetmap.org/viewtopic.php?id=74790

UK is considering it: https://lists.openstreetmap.org/pipermail/tagging/2022-February/063871.html

this is what I know of at the moment. It's great when country specific communities organize themselves to do it. Currently I'm more engaged with trying to convince one of carto maintainers to accept my pull request to render the features on the map (https://github.com/gravitystorm/openstreetmap-carto/pull/4512) but once this is complete and retagging is done in Poland hopefully we'll be able to help with other countries. --Tomczk (talk) 00:19, 7 February 2022 (UTC)