Luggage lockers with pick up and mail in services

General talk Tagging general discussion
1

I just noticed that several station lockers in the Tokyo area are replaced with multi-functional lockers with storage, mail in, and pick up services. You can store your luggage with a fee, send your suitcase/parcels to hotel/home, and redirect your parcels to the locker to pick them up.

Photo:

Photo of the control panel for the lockers
Photo of the control panel for the lockers1920×2550 285 KB

How would you tag these lockers? Does it make sense to tag them as amenity=luggage_locker + parcel_mail_in=yes + parcel_pickup=yes? (OSM wiki says you should not use parcel_mail_in and parcel_pickup without amenity=parcel_locker though).

2

Photo of one cluster of the multi-functional lockers
Photo of one cluster of the multi-functional lockers1920×1446 327 KB

3

I would consider putting two separate nodes, like I would do with shop selling honey and cars.

4

In Germany something similar popped up: Sending and receiving of packages, storage of luggage and pick-up of things from local vendors:

5

Thanks. Tagging with separate nodes for amenity=pacel_locker and amenity=luggage_locker can be an option. Although, duplicating general tags such as name=*, brand=*, operator=* and ref=* may be cumbersome without proper editor support. And tags like capacity=* would be ambiguous: the number of boxes could be counted twice if you would tag both nodes.

6

That is precisely why I would reject tagging with two separate nodes.
This is an object with multiple functions. In my opinion, it would make more sense to add a key to amenity=pacel_locker, such as luggage_locker=yes|onsite|online or vice versa.
I know from Germany that these combined stations can be booked as luggage storage via an online platform, but not directly on site at the station.

7

I agree, two different nodes is not the solution here (unlike the car dealership selling also honey, where I can agree with 2 objects (but could also be a property of the car dealer: sells:honey=yes)).
These are multifunctional lockers and we have basically 3 options:

  1. introduce a new “main tag”
  2. tag it as parcel_locker and have an additional property for the luggage locker function
  3. tag it as luggage locker with the parcel drop and pickup as additional functions
    (plus the delivery to hotels in each case).

There is also a proposal to define amenity=locker as generic locker: Proposal:Locker - OpenStreetMap Wiki
then 2 years ago someone decided size should be the distinguishing factor and added it to the wiki, but I am not sure this is the general consensus and usage is still low, so it could maybe become a generic locker tag from point 1., to be further specified if possible.

Or maybe amenity=electronic_locker? multi_locker? connected_locker? smart_locker?

1 Like
8

I’m reminded of what @SafetyIng proposed before Proposal:Unified postal service tagging - OpenStreetMap Wiki
I would indeed suggest the post_office= method from shops, and to treat them as some locker feature with postal services. 3 is more informative, as they can be more easily full than parcel lockers from luggages, meaning they are less dependable, only for convenience if available. However, there’s a further possibility of =luggage_storage handling both lockers and =left_luggage together that I like more. Proposal talk:Luggage locker (2017) - OpenStreetMap Wiki

1 Like
9

The lockers in Tokyo that I mentioned can also be booked online (with an extra fee). If we adopt luggage_locker:* prefix, we can reuse reservation:* tags to specify how to book the lockers, like luggage_locker=yes + luggage_locker:reservation=yes + luggage_locker:reservation:website=*, which I think more extensible (+ maybe luggage_locker:reservation:fee=yes).

10

Or maybe amenity=electronic_locker? multi_locker? connected_locker? smart_locker?

I’m afraid it doesn’t work well to introduce new amenity= value to represent some specific multifunctional amenity, as it could easily break if new service combinations appear in the future.

I think amenity=locker is generally useful for mapping various kinds of lockers (e.g., shoe lockers, umbrella lockers, ski lockers, key lockers). A locker’s primary purpose is to store items, and the mail-in/pick-up service seems like a separate function rather than part of the locker itself. Parcel services are not necessarily provided by a facility that looks or behaves like a locker—for example, postbox-like machines can also accept outgoing parcels. So, I believe it would work better if lockers could be combined with parcel-related services, rather than trying to integrate them into the locker amenity.

11

I would agree and support this type.

12

The idea was to specify also individual features as properties, so this would naturally be extendable.

13

But they are in the same machine, it is multifunctional, like sometimes a kisok also sale tabacco, and share some infrastructure between those luggage and parcel storage function

14

In fact, I would like to have a broader and more comprehensive tag in OSM that describes “providing a space that can be rented” rather than just parcel or luggage. However, it seems that the cost of promoting a new tag is too high.