What is the correct way to tag a CBU cluster mailbox? These have an outgoing mail slot, many individually-locking boxes for addresses, and usually some parcel lockers. There can be dozens of addresses that send and receive mail from one box cluster. Should we use the same tags as the Canadian equivalent?
The Canadian equivalent, according to your link, is to use amenity=post_box; but that is explicitly for outgoing mail according to the wiki. USPS CBUs are primarily for incomining mail, even if they allow for outgoing. I do not know what the best tagging scheme is, but my best guess is to map each physical cluster as amenity=letter_box with post:flats=address numbers to indicate multiple slots/boxes. --MRPockets (talk) 16:17, 12 February 2025 (UTC)
These are not well tagged under the amenity key IMHO. I'm all for people mapping whatever they like, but amenity is not a good key for private things that nobody cares about then yourself. --Dieterdreist (talk) 14:57, 8 October 2018 (UTC)
Not rendered?
So is there an example we can see on the map, or are all Tag:amenity=letter box invisible? Jidanni (talk) 22:25, 11 June 2019 (UTC)
rendering them on the standard style would somehow confirm the tagging, which is IMHO not desirable, these aren’t amenities, not more than your front door or the waste bin in your kitchen. —Dieterdreist (talk) 08:00, 12 June 2019 (UTC)
amenity key is perfectly fine here, and not a reason for not rendering them Mateusz Konieczny (talk) 08:25, 12 June 2019 (UTC)
You are aware that this is about these private boxes: and not about amenity=post_box? Under which definition of amenity these would suit "perfectly fine"? The amenity key says it is "Covering an assortment of community facilities including toilets, telephones, banks, pharmacies and schools." IMHO these are not "community facilities" --Dieterdreist (talk) 10:34, 12 June 2019 (UTC)
Yes. I fixed description on Key:amenity, reusing one from infobox. Amenity key is already widely used also for private features, like over 250k private parking. Mateusz Konieczny (talk) 10:18, 14 June 2019 (UTC)
For me it doesn't seem reasonable to copy the problems with parking to other features. It should also be noted that parkings exist in different manifestations, ranging from free and public to unaccessible and private, while private letterboxes are always private. I stand by my comment above: bad choice for the key.--Dieterdreist (talk) 13:15, 14 June 2019 (UTC)
I think we will agree that we disagree here, I still see no benefit from inventing new keys Mateusz Konieczny (talk) 07:39, 15 June 2019 (UTC)
This tag would be very useful for letter carriers that are new to a route.
(They are certainly private in the sense of being "for the use of one particular person or group of people only"; but as for who owns them, often it would the USPS.)
The wiki says "Mailboxes for several addresses are regularly combined in one place (for example per street in rural areas, or at the front door of an apartment, for a group of trailers in a trailer park) — then use just one single node instead of 20 separate ones.:
However, there is a problem for multiple addresses. As an example, an apartment complex: it has two buildings, and each building as its own street number.
For instance, one is post:city=West Blah / post:flats=109-120 / post:housenumber=1051 / post:postcode=99999 / post:state=XX / post:street=1st Street,
To that, I cannot concatenate
post:flats=85-96 / post:housenumber=1060 / post:street=2nd Street East
To keep them separate would also allow to tie ("relation"?) a specific mailbox to a specific building. This is very useful in some cases:
if a package does not fit in the letterbox and needs to be brought to the door of the apartment.
viceversa, if we need to deliver a letter for an address and don't know if there is a corresponding CBU and its precise location. --Juan Zuluaga 19:59, 23 January 2025 (UTC)
post:*=* on amenity=letter_box is mostly intended for simple cases. Indeed, although technically possible, it's not realistic to create amenity=letter_box for these separately. There is type=provides_feature I can think of. You would relate the amenity=letter_box (no role for it yet, could start letter_box ) , with the addr:*=* / building=* as target . This has no support yet, although I suspect post:*=* is not used by any application either. Alternatively, you might try a specific definition and usage for commas and semicolons. Some attributes does this, viz traffic_sign=* , and some other I forgot. Karlsruhe schema actually used comma, unlike semicolon elsewhere.
post:flats=109,110;85,86 (example for illustration)
So 109,110 would be interpreted as for 1051 1st St only. However as your case is post:flats=109-120;85-96 , it's unclear what it means. You need to add a note=* to reminds others. In either case, you can simply use description=* to describe. It may be possible to use post:full=* similar to addr:full=* , although it looks funny, and I personally don't really like the post:*=* format. —— Kovposch (talk) 08:02, 24 January 2025 (UTC)
letter_box ) , with the addr:*=* / building=* as