In Germany, DHL Group (Deutsche Post AG) is expanding its service at the previous parcel lockers into so-called “poststations”. This small proposal takes this into account and aims to summarize postal services in general.
https://wiki.openstreetmap.org/wiki/Proposal:Unification_of_post/parcel_keys
Here an example of a “poststation”
“For amenity=parcel_locker the keys from the namespace post_office:=* are used instead.”
which ones?
post_office:parcel_pickup=* ? But parcel locker is not a post office… If anything I would change post_office:parcel_pickup=* to parcel_pickup=*
Yes that. But this makes a good question. Cluster box unit and community mailbox with both letter deposits, and parcel reeving, have been discussed before for =letter_box . The issue becomes why not create a separate =mail_box point for these.
I recommend solving them together as a comprehensive solution offering more improvements. Not merely renaming.
Most often used key from post_office:* namespace has 2 490 uses, (parcel_pickup has 23 742).
Proposed tagging is too localized - you want to deprecate tagging used everywhere else.
Current tagging probably can be improved, but that proposal is not making it better in my opinion.
Then to create 10 new top level keys? Sorry, postal services are not so importent to have any top level keys.
No, I just want to prefer the technically advanced. This can be expanded more easily later.
FYI: post:office:type is deprecated. It should used post_office=* instead.
You aren’t explaining how your method isn’t violating it. This can be said as mixing =parcel_locker and =post_box . The functions materializing in the form of the slots can be considered separate features, that should be added as 2 objects. One Feature would apply to the entire locker machine. It’s similar to a building= having multiple shop= inside, even if the counter is next to each other in the same room.
No, because effectively everything at this station is controlled via the display. So in your comparison you would have a store where 3 or 4 stores share the same cash register and counter. They are one unit. Not just a shell.
If in a restaurant, I can order from one touch panel to get food from 2 different brands selling 2 different types of food from each of their counter, they could still be added as 2 amenity= . No?
The function of =parcel_locker is defined for parcels, and =post_box is defined for mails. You would cause mail sending functions not represented by =post_box .
And you haven’t mentioned how to handle different collection_times= if that can happen. As well as ref= and other attributes, when different.
Aren’t you equally suggesting this issue may be argued as not important to warrant a vote to change them? You are deprecating 2 top-level attribute as well. Why should post_office:*= be used if it’s not a post_office= ? Semantically, that is another worsening when eliminating the duplicates in parcel_*= and post_office:*= on one hand.
The format is already rooted in prefixing post_office:*= for a amenity= / shop= + post_office= .
To my understanding you would like that each of these must have at least 2 objects. To me, that appears to be a little over the top – for a classic, human operated post office, would you really always map several objects e.g. one for parcel, one for letters, one for selling stamps, one for finance? 
I usually only do one object with all features, and if one object does not nicely fit e.g. because opening_hours or ref do differ, I split into several distinct objects. I don’t see a reason to make a difference whether it’s human operated or “automated post office” – IMHO we shall allow both, one combined object as well as dedicated objects. Further on, I do not see any disadvantage: By re-using post_office:* keys, existing applications’ search, filtering etc. shall work as it does with post offices, existing mappers do not need to learn anything new, and new mappers do not need to learn about two tagging schemes with mostly same meaning (post_office:parcel_pickup=* and parcel_pickup=*) but just one.
In case we use – for whetever reasons – two distinct objects for letters and for parcels, for the letter part, I guess we’ll also need a new value for post_box:mounting and post_box:type but I am having no good ideas.
While I’d also prefer one single, consistent, semantically meaningful tagging scheme for all variations of postal services, I have in mind how intense postal tags have been debated in the past, and quite often based on local/regional heritage & specifics & wordings. Hence, I really doubt we as a community will be able to agree on one consolidated postal tagging scheme as of now – maybe in 15 years, when the community spirit changed a little. Hence, I’d strongly suggest the proposal shall be as narrow as possible at the moment so it’s easier to agree and we can move forward.
A =post_office is understood to be possible to do all of them. But now a =parcel_locker is for parcels, and =post_box is for letters.
In detail, similar to =atm attached to a =bank , you could create =parcel_locker and =post_box when they exist outside a =post_office . If there a machine selling stamps, it can again be created as =vending_machine + vending=stamps , not needing to be an attribute of =parcel_locker or =post_box , nor the =post_office .
Unlike =atm where there is no separate =cheque_deposit_machine , =cash_deposit_machine , etc (because they are commonly combined already, possible to use cash_in= ), postal has =letter_box and =post_box before =parcel_locker .
Indeed, the latter two are one-trick-ponys and we have dedicated, very common words for them. The machines that caused this thread are different. They offer all functions in one object, so they are in fact offering exactly the services you’d expect from a post_office=* – hence, something like post_office=automated or post_office=machine or the like would be most consistent to the traditional post_office=bureau. This approach also avoids a creeping scope for amenity=parcel_locker, i.e. we’d keep that value very clear & precise.
It is a very good question. automated= / self_service= has been used for =fuel , car_wash= , =laundry , etc. (Don’t know what are the solutions for modern automated convenience stores) For =bank , we may not want to use it for a room with only ATM, if there is an expectation of human service.
Do you mean using amenity=post_office + post_office= for them? It’s complicated, when shop= + post_office=post_partner doesn’t need it to be the main feature.
I had the thought =parcel_locker + post_office= may also be acceptable. This balances the compatibility of existing =parcel_locker , and gets around the semantic issue of post_office:*= . However, the other combined =post_box + =letter_box + =parcel_locker cabinets I mentioned remains unsolved.
For the =post_office option, I prefer using automated= / self_service= . Unfortunately, there needs to be something for the post_office= . In between your two example, I would choose post_office=machine to avoid the wording of automated=.
In extension, this may allow distinguishing a machine alone with post_office=machine, and a dedicated shop space or room housing one or more machine with eg post_office=automated_store . This is inspired by the terminology of automated convenience stores.
Though I read there are some stations that have postal machines connected with ATM, vending machines, and maybe more in the future (cash change machine?). Can’t decide which one they should use. Or maybe this should be a 3rd category eg post_office=kiosk + automated=only ? News
Existing =post_office can have self_service= / automated= added when there are machines outside for longer or 24/7 hours, similar to =bank + atm=yes . They can use the same full_service=yes + self_service:conditional= format as =fuel . .
parcel_locker=yes should be allowed. Same for vending_machine=stamps .
The difference of self_service= and automated= needs to be clarified. Was discussed for other features last month. Self service petrol stations - what does it mean
