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.
Here an example of a “poststation”
“For amenity=parcel_locker the keys from the namespace post_office:=* are used instead.”
post_office:parcel_pickup=* ? But parcel locker is not a post office… If anything I would change
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.
Because we have there a good mapping practice
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
=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
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
post_office:*= on one hand.
The format is already rooted in prefixing
post_office:*= for a
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
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 (
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: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.
=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
=post_box when they exist outside a
=post_office . If there a machine selling stamps, it can again be created as
vending=stamps , not needing to be an attribute of
=post_box , nor the
=atm where there is no separate
=cash_deposit_machine , etc (because they are commonly combined already, possible to use
cash_in= ), postal has
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=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.
self_service= has been used for
=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
post_office= for them? It’s complicated, when
post_office=post_partner doesn’t need it to be the main feature.
I had the thought
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
=parcel_locker cabinets I mentioned remains unsolved.
=post_office option, I prefer using
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
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
automated=only ? News
=post_office can have
automated= added when there are machines outside for longer or 24/7 hours, similar to
atm=yes . They can use the same
self_service:conditional= format as
=fuel . .
parcel_locker=yes should be allowed. Same for
The difference of
automated= needs to be clarified. Was discussed for other features last month. Self service petrol stations - what does it mean