On the wiki page for amenity=parcel_locker there is a section which describes a disagreement about whether to use name or ref for the non-unique amazon locker identifiers. They are displayed prominently on the parcel locker. Here’s a picture I took of one recently:
The name Amazon Locker - [identifier] is consistent with how they are labeled on the Amazon website, but doesn’t appear anywhere on the lockers themselves.
It’s not clear to me that the non-uniqueness of these identifiers make them unsuitable for ref, because I can’t find anything on the wiki that says that. I’m interested to hear how the community thinks these should be tagged.
I guess it depends on how they are used. ref doesn’t have to be unique (see basically every interstate), but still refer to basically a single object or concept.
Having two lockers with the same name usually precludes that. Additionally, from the quick search I made, I don’t think that the names are used internally to refer to the lockers.
I rather think that it’s just a display name, in which case it’d be probably best tagged name=[identifier] as that’s what’s posted on the sign.
At the end of the day, only Amazon knows what the purpose of those names is.
I believe that the names are locally unique, but I haven’t actually confirmed this. They serve as a wayfinding tool when there are multiple lockers close together. Also, it looks like they have a unique numerical identifier which they use internally, but it’s not presented to the user in any way.
My personal opinion would be to keep the name empty and use ref=matt for the one in your picture. People would never refer to these by their name, only by “that amazon locker on the parking lot of XYZ”[1]. name=Amazon Locker - [identifier] seems clearly wrong to me, as we usually don’t add the functionality to the name, especially not if it’s not even part of what could be the name.
I personally distinguish between ref and name by checking how people would refer to them. If there’s a bench labelled “Brad” somewhere in the wilds, will people say “sit down on Brad”, or rather “sit down on the bench called/labelled Brad”? Will you say “I’m going to <company name>”, or “company <name>”? But that might just be me ↩︎
Initially I thought they were unique for every country: in the OSM database we have two “lavendar”, but one is in UK and one in Germay. But then I found two/three “alva” in Germany alone so I’m not sure anymore.
It’s not clear to me that the non-uniqueness of these identifiers make them unsuitable for ref, because I can’t find anything on the wiki that says that. I’m interested to hear how the community thinks these should be tagged.
Um, ref is an identifier (first sentence of Key:ref). The English word identifier means unique, if something is not unique, it’s not an identifier.
If the lockers had a label on the back with the unique code LCKR_16401_37, there would be no confusion that that’s the ref, similar to how we map electric charge devices and light poles.
That weird code does exist today on Amazon’s servers, even if it was not yet made public.
The parcel is not targeted to alva (there are 2 in Germany), it’s targeted to LCKR_16401_37.
Edit for clarity: the two alva certainly have different identifiers, which are most likely very different from each other, for example LCKR_16401_37 and LCKR_95672_58.
Amazon does not refer to the locker by name. Amazon refers by an internal code and shows a human-friendly name to the end user. But there’s nothing special in that, it’s how any website and software does.
Another way of seeing it:
ref is meant for the data consumer (maps app, database, …) to lookup info from a non-OSM source of information. In the case of lockers, it is the primary key of Amazon’s list of lockers and a foreign key in OSM.
For example, if Amazon decides that each locker has a dedicated webpage, the search result will link https://... which will spell out the locker’s unique identifier. That won’t be alva or matt, because alva is present twice in Germany (source amenity=parcel_locker) and the website would have no way to know which one locker is intended, just from the link.
And a maps app will never be able to do anything with ref=alva:
cannot lookup info from a non-OSM source of info about lockers (because there are 2 alva)
cannot generate the proper https:// in the hypothetical example from above
Context is important. This technical meaning of refer is different from @Nadjita’s more informal meaning. Amazon calls the locker “matt” and publicly displays this name.
ref is always relative to some database. This can mean that other tags (like highway or amenity) might be needed to uniquely determine the object that is referenced.
You seem to have inside knowledge of Amazons locker system, so maybe you can make that determination. But publicly, we don’t know that. Ultimately, in both cases we cannot use ref. Instead use name.
Out of curiosity I went to check, and indeed they have codes of some kind on the back (at least this one, in Italy), the problem is that I found two on the same locker, so I wonder what they identify. Maybe they identify the same locker but in two different lists, an european one and a country specific one.
I think you’re reading a bit too much into ref. It’s really just a “reference” It doesn’t have to be unique or unambiguous. Most of the ref-codes commonly used are, but it’s not a requirement.
The German DHL parcel locker ref-numbers are also non-unique. They aren’t even unique in the same city, and everyone knew that before, because they use only 3 digits and there’s several thousands of them, so the common claim that “people only use ref, because they think it is unique” isn’t really valid. Given the names of Amazon lockers that I know, I dind’t expect them to be unique either, but who cares? If amazon tells me it delivers to the locker “whale”, I’m going to search in the area where I live for the closest locker matching that ref or name, and that’s it. Same that I do for DHL parcel lockers.
Website labels should be assumed as labels, not proper names. The hyphen is a red flag.
In other features (including =charging_station ), name= would be the brand= (except eg =hotel ). So if there’s no other location used, I suggest considering eg branch= for its use in identifying each, even though it’s not a location. “Amazon Locker - Rushmore” is similar to how other shops would show eg “ABC Supermarket - Sometown” online.
There’s no such meaning in English. An identifier simply identifies. That’s why there are eg GUID/UUID. Unique identifier - Wikipedia
It’s surely possible for a standard identifier to repeat for different reasons, although they may be considered for other *_ref= if possible. That said, for the case here, I definitely agree it should not be ref=Matt , at least not ref= . It doesn’t seem to be other *_ref= either.
I believe DHL ref-numbers are unique with the postal code.
But whether a ref is unique or not isn’t what I’m getting at. It’s what it’s being used for that makes the determination for me. A good name is also a good ref if you want to. Human-readable names are usually intended to be used by humans, so that’s more like a name. The fact that we’ve been getting used to ref-numbers whose purpose isn’t primarily human-oriented (smaller storage, better localisation, faster processing by computers) doesn’t stand in the way of that.
If you want to include that no person uses the name set by Amazon, you may use official_name instead. I don’t think that fragmentation is necessary though.
I don’t think branch is appropriate here. “This is our Matt branch”?! And of course the Wiki page itself says that what can be seen on the outside should be put into name.
Different people can come up with the same design. I don’t think that the intention here was to set up branches for every locker.
If you want to consider how it should be introduced, it won’t be called a “branch” anyway. But branch= is already being used for referring to different locations of other features. There’s not much need to invent or use something else for the same concept. “This is the Sometown store”, “This is the Matt locker”, or similar. branch= seems a easier solution that can avoid name= vs ref= controversies.
The sign will show “Amazon Locker”, or “Amazon”, etc. It’s still not used in name= as a standard yet.
I’ve mapped a few Amazon lockers and have always put the “matt” name in the ref field. I think it makes some sense to do that way, although maybe I’m biased because I don’t want to think I did it wrong! I also have used Amazon lockers to receive packages, and the “matt” is definitely useful for making sure you’re at the right one – in the Amazon UI when you place your order, it specifically includes the “matt” in your delivery location.
I do not think the “matt” should only be available in the name field next to “Amazon Locker”, because regardless of whether “matt” is globally unique, it does specifically identify the locker locally, and help differentiate from other lockers nearby. I think the best readability for both humans and machines would be tagging it as:
key1=Amazon Locker key2=matt
I think key1 being name and key2 being ref is fairly logical. I actually think key2 being branch would make even more sense, even though as @Jofban points out it does sound absurd to call it the matt branch.
It’s worth noting I’ve seen several renderers put the ref directly after the name when displaying features. OsmAnd does this, as does the default Carto display for this node.
I believe you that it’s useful, otherwise it wouldn’t belong into OSM at all. The question is only where to put that information. Regardless of that though, thanks for mapping it in the first place!
Sure does, but you can make that argument for basically anything. If I were to tag myself, my identifier Jofban “does specifically identify the [user] locally, and help differentiate from other [users] nearby.” So clearly ref=Jofban? No, it’s a name for you to call me by, so name is better imo.
key1 is clearly brand, no need to duplicate that. key2 is the point of discussion.
