Proposal talk:Locker

Size details

There might be interest in further specifying the size of lockers at the place. Add your ideas here.

• height=* for the interior height of a single locker
• width=* for the interior width of a single locker
• length=* for the interior length of a single locker -- Warin61 (talk) 22:01, 18 February 2017 (UTC)

Capacity confusion

The key capacity=* is presently used in OSM to specify the number of things, e.g. the number of car parking spaces in a parking lot, rather than the volume/size. To me the use of capacity=* would specify the number of lockers here ... not their size. I would use another word for this property of size/volume .. perhaps volume? Warin61 (talk) 21:57, 18 February 2017 (UTC)

Yes, the capacity key is proposed for the number of lockers. The size classes could be used like this: capacity:big=10 capacity:medium=30 capacity:small=40, but I don't like big or small as denominators because they are completely relative. Something more self-documenting, like 'handbag', 'purse', 'two big suitcases', etc. might be better, but I haven't thought more about it yet. --Dieterdreist (talk) 17:59, 19 February 2017 (UTC)

Locker Type

It would valuable to document a tag such as locker:type=*. For instance locker:type=bicycle, locker:type=luggage. The default (no locker:type) could indicate a generic locker. Daviewales (talk) 23:27, 26 March 2019 (UTC)

I agree it would be useful and changed the proposal. It now suggests to add locker=*. --Dieterdreist (talk) 09:09, 27 March 2019 (UTC)

I stumbled upon this very useful proposal. A more specific (also direct and high-level, without the ambguious and contradictory type=*) key such as content=* (may I suggest using it in this role instead of conflicting with substance=*) would be more straight to the point, if not further a key for the item itself cf amenity=give_box (Tag:amenity=give_box#Related_facilities). locker=* should be reserved for the most distinguishing or uncategorized properties. Therefore, I would further suggest consolidating Proposed features/Luggage locker into this as Talk:Proposed_features/Luggage_locker#Yes for amenity=locker, no for amenity=luggage_locker commented. -- Kovposch (talk) 04:50, 26 March 2020 (UTC)

content=* doesn't seem right, because the content is whatever individuals put in there. That varies. What does not vary is the *intended* use (intended content). The locker=* subkey seems perfectly fine for this. But a key name like locker:use=* might also be considered. --Fkv (talk) 03:33, 25 October 2021 (UTC)

In libraries, museums, sports centers and some schools, the lockers are used to store bags AND outdoor/non-sports clothes (such as coats) and also valuables (wallet, keys...). A tag value locker=luggage doesn't seem to properly reflect this. Maybe locker=clothes, because whereever you lock your clothes, you can also store medium-sized bags. --Fkv (talk) 03:33, 25 October 2021 (UTC)

I agree that the tall lockers where you can hang a coat could be distinguished with their own subtype. If you go into capacity tagging or a place has only one type of lockers, but often there will be a mix. For the smaller, museum/library style, maybe “handbags”? —Dieterdreist (talk) 20:38, 2 November 2021 (UTC)

What I was trying to express is not that there is a variety in compartment sizes (although that is also true), but that every single compartment is used to store clothes as well as bags. I think it makes no sense to distinguish such values. That would mean to enforce comma-separated multi-value strings such as "wardrobe;handbag" on virtually every locker in the world. Such multi-values are loathed by many mappers and ignored by all applications that I know. --Fkv (talk) 00:02, 3 November 2021 (UTC)

The type does not describe what you can put into the locker, it describes a certain dimension and shape which results from the presumed intended usage, e.g. wardrobe means intended to put clothes in (hangers, tall size), while handbag means too small for a suitcase, but you could put your cellphone in. Of course you could put a pile of handbags in the wardrobe locker, it doesn’t imply you will have to use comma separated values, on the contrary as these are types, you should have /find only one type that corresponds with the locker that you are tagging. —Dieterdreist (talk) 00:58, 3 November 2021 (UTC)

The intended usage of a locker in a library is that you put in everything that you don't need in the reading room. That includes clothes, bags, phone, radio, food, drinks, wallet, umbrella, penknive, weapons...

If you want a tag for compartment sizes, why not locker:size=* ? Values either 1/2/3... (with definitions in the wiki) or suitcase/handbag/... --Fkv (talk) 01:34, 3 November 2021 (UTC)

I also think that it is important to think in particular of the ambiguous cases when one wants to define different types (a categorisation). This shows whether you have chosen good types ... And it is not very easy to describe all cases that occur in practice (at least the frequently occurring ones). E.g.: using the size as a criterion seems to be a good idea at first glance, because it is simple and easy to understand. But on second glance, the case is probably very common that there are lockers of different sizes (for different items) in ONE place, e.g. in a museum. Therefore, the type values should perhaps describe the (main) nature of the items more than specific items themselves which are placeholders for a certain size (or there should be more general values for the ambiguous cases AND more specific values for the easy cases with only ONE very specific kind of lockers – like the type wardrobe). For lockers in museums, libraries and so on (different sizes), a quite general value could perhaps be something like locker=personal_items? This would include bags, clothes, phones, umbrellas, ... and it's independent of the size. Other values that I find OK in principle are: locker=luggage (because it is very common in train stations, airports etc. and describes the main purpose of the locker and it's also independent of the size – and the rare cases like a bag full of stolen money can be neglected), locker=bicycle (BUT: there is already amenity=bicycle_parking + bicycle_parking=lockers – so it's perhaps not a good idea, specially because both are amenity=* keys – except if this value should describe bicycle lockers which are not meant to park a bike, e.g. for loading an e-bike, which should be made clear in the description of the value), locker=wardrobe (common and typical in schools, sports centers and so on). And I think it's less important that the types are distinct/unique types with no overlaps (for example: "luggage" perhaps also falls under the category "personal item"). And I think that the size is not a very essential factor that needs to be described in the context of a locker, because the term "locker" already implies a not too wide range of sizes and there are other terms and keys for other sizes and uses (example: for a car locker there is already building=garage, for the general storage of materials there is e.g. man_made=storage_tank or man_made=silo or ...). It's never easy to categorize ... but collecting ideas may be a good thing ... And I would think it would be a good idea to add typical photo examples for the values in the proposal ... --Goodidea (talk) 00:29, 1 November 2022 (UTC)

lock type

fee=* and payment=* don't seem sufficient for those lockers where you insert a coin to get the key, and then you get the coin back when you insert the key again. Ok, you can set fee=no + payment:coins=yes, but it's still counter-intuitive, particularly when we consider that the same mechanism is also used on shopping carts in supermarkets where you do actually pay for your purchase and you can pay for your purchase with a debit card. Maybe lock:operation=* ? But this needs a separate proposal, because it applies to all kinds of locks (on doors, gates...). --Fkv (talk) 04:10, 25 October 2021 (UTC)

fee=deposit? There's already trolley:deposit=*, but I'm not sure it should be locker:deposit=* so that everything gets a *:deposit=*. reservation=* could use this too.

I don't entirely agree the coin should be considered the locking mechanism. You get a key from it. Cf authentication:*=*.

---- Kovposch (talk) 03:21, 3 November 2021 (UTC)

One should distinguish clearly the different concepts: fee=* means if the usage of a locker is free or not (a useful piece of information), authentication=* would mean you have to register yourself somewhere before you can use a locker (or not with authentication:none=yes) and perhaps the “lock type” which describes the locking/unlocking mechanism of a locker (which can be: insert a coin and get a physical key, get the coin back later. Or: choose a number code on a keypad as a locking and unlocking code which is valid as a one time code. Or some other more or less intelligent mechanism ... perhaps an iris scan ... and not to forget: perhaps more than only one “lock/unlock type” could be possible on a locker). Only wanted to mention this.

And yes – this would also apply to other objects which can be locked like doors, gates, key safes ..., so it should be a universal subkey (= separate proposal), if you want to tag this at all. I would ignore this for now, because locking mechanisms for lockers have one thing in common: they are usually designed in such a way that almost everyone can use them without major problems. And to distinguish the different locking designs does not have a major additional benefit – apart from the joy of microtagging, of course (or for the information that you need a coin …). By the way: description=* can also be used for such less relevant things, or before a good key is proposed. Perhaps more important would be whether they are barrier-free, e.g. whether they can also be used by blind or disabled people (e.g. for a "keypad locker" you first have to read the instructions how to choose and enter a code for locking/unlocking, all in all surely not easy to use for a blind person). --Goodidea (talk) 01:25, 1 November 2022 (UTC)

How to proceed?

5 years and nothing has happened. Still a "proposed feature". How to move forward and get such an essential tag approved? --Rene78 (talk) 12:10, 24 June 2022 (UTC)

--Chatelao (talk) 14:04, 26 June 2022 (UTC) totally agree, how to proceed?

See Proposal process Something B (talk) 23:06, 20 December 2022 (UTC)

Parcel lockers

This proposal will now have to take into account the approved tag amenity=parcel_locker. It would’ve been wiser to vote this one before and make parcels a subtag but what’s done is done. --Lejun (talk) 11:06, 5 October 2022 (UTC)

I think a parcel locker is quite a different concept (feature) than a “locker“, although it uses the same term (so it's not a problem and I also think it wouldn't be a wise subtag for amenity=locker). It's for sending or receiving parcel (and it even doesn't necessarily have to have single locker boxes – the type "parcel box" is just one big box, where you and others can insert your parcel for sending, see parcel_locker:type=* – I don't think that would ever exist for a “locker” in the intended sense). The concept of amenity=locker should only have a good definition of what a locker is (the proposal still lacks that), e.g. “A amenity=locker is a lockable box for the safe, temporary deposit or storage of items.” (this would clearly distinguish it from a parcel locker). --Goodidea (talk) 02:10, 1 November 2022 (UTC)

Ski depot

I would like to propose an additional locker type that might be of interest for skiers:

• locker=ski - a locker intended to hold at least one pair of skis. Also known as ski depot. 4 lockers have been tagged like this as of now, but there is one in every major ski resort. --AlesKubr (talk) 22:39, 28 February 2023 (UTC)