This proposal aims to clarify and formalize some elements of the drive-through used in fast food, banks, pharmacies, liquor stores, and elsewhere to execute sales without the customer leaving their vehicle.
Tags: board_type=menu, man_made=speaker_box, speaker_box=yes, window=drive_through. parking_space=pickup.
https://wiki.openstreetmap.org/wiki/Proposal:Drive-Through_Elements
Please discuss this proposal on its Wiki Talk page.
I’m concerned that using this tag for the location where the customer receives their order could lead to situations where that meaning clashes with the main purpose of window=* nodes (which is to map the physical reality). For example: What if some place is using an open door instead of a window to hand people their orders? Or an outdoor counter under some roof or canopy?
I think this could be avoided by defining a tag that is strictly about the function (I.e. “the location where the customer transacts or receives their order”). That tag could then be combined with window=* on the same node if it is indeed a window.
Hi @Tordanik, i am not sure i am following. A window is not a door or a table. Windows are not required to be a part of a drive-through (Chick-fil-a and new banks come to mind) but are a common element.
The proposal describes it as
The window(s) where the customer transacts or receives their order. If multiple are present, consider how they are labelled to use a key such as ref=*.
You could perhaps say we should have a “openable” tag on windows which would apply here, but I see drive-through windows as common enough that people know what they are and would be easy to map and verify.
So window=drive_through would not be used for these drive-through objects?
Let me attempt to describe the issue in different words:
Sometimes, the location where the customer receives their order is not a window. Your proposed tags cannot represent this situation.
That’s a problem for potential data consumers who care about the layout of drive-through establishments: For the use case of directing customers to the place where they can pick up their orders, it’s mostly irrelevant whether that location is a window.
It’s also a problem for data consumers who care about windows: If there’s no proper solution for non-window pickup locations, some mappers who care about the previously mentioned use case will inevitably misuse window=drive_through for those locations.
Therefore, I’m suggesting that your proposal should include a tag for “the location where the customer transacts or receives their order” which can be used whether or not that location is a window.
see historic=wayside_shrines used also for ones built months ago or not next to road
or natural=tree that initially was supposed to be used for notable trees
this happened many times already, and is not only a theoretical concern
Ah I see! I have considered a “highway=stop” type tag for the way to designate order/payment/pickup spots on the drive-through way. Would that work you think?
Ah I see! I have considered a “highway=stop” type tag for the way to designate order/payment/pickup spots on the drive-through way. Would that work you think?
it works to mark a stop, but not to designate such specific spots as you have in mind, it is a generic tag and has generic implications.
That’s why I was thinking something like “highway=stop” “stop=drive_through” or something similar.
=stop means stop then proceed when clear. Drive-thru is more than that.
Would be similar to barrier=toll_booth , or amenity=ticket_validator which can be attached on the road line. An eg amenity=drive_through could be fine, or highway=drive_through to emphasize it should connected on the highway= if amenity= may be used for the entire area covering everything related.
While it can be worked on further, window= has already been described as “function/type of the window (e.g. display_window)”, meaning this is not a unique problem. You have more ideas now as an author? Key:window - OpenStreetMap Wiki
On the other hand, in general, a generic solution could also be pursued for all such point-of-contact. Windows, counters/desks, doors. Drive-thru, general purchase, take-out, ticketing, info, help. Proper buildings, kiosks, booths. Which isn’t entrance= , let alone door= or window= . Depends on how it should be formulated, as there is already amenity=reception* etc.
This reminds me of curbside pickup. At the start of the pandemic, pretty much every store or restaurant that reopened in the U.S. offered that service, and some prominent chains like Target continue to offer it today. However, a characteristic of curbside pickup is that there isn’t a drive-through to speak of. Usually there’s only a pickup zone reserved at the edge of the parking lot (along the “curb”) or, in Target’s case, some dedicated parking spaces that an employee will attend to.
I don’t think this situation would call for tagging a node along a service road. Navigating to a subdestination, such as a curbside pickup zone, would be the geocoder’s job; a geocoder would need to know that it’s associated with the shop, not so much that it’s connected to the road network. As for a conventional drive-through, there’s infrastructure (a window) that matters more to detailed 3D renderers than navigation software, which could target the service=drive-through way anyways.
By the way, “How do I tag a drive-through window?” doesn’t come up nearly as often in OSMUS Slack as “How do I tag a walk-up window?” It might be worth thinking about how to coordinate tagging for both situations. I think walk-up windows pose the more interesting challenge, since there isn’t any additional infrastructure to clue a data consumer into its general location. So far, the leading contenders seem to be amenity=takeaway_window and window=walk-up – which isn’t saying much at 16 elements between them.
Indeed that’s what I suggested to explore above. There’s 1 inappropriate ``=Reception Window` , ~40 “ticket window” too.
There’s another question of naming to distinguish these pick-up position of shops, from dedicated shops where you can only pick up prior orders Proposal:Pickup points - OpenStreetMap Wiki
That proposal considers both dedicated shops and parcel lockers, but a PUDO point can also consist of an arrangement with some business to accept packages at a reception desk, in the same manner as a post_office=post_partner. For example, until a couple years ago, the San José mapping community used to meet at a coworking space where the receptionist’s desk at the front partnered with a PUDO network. There wasn’t anything to it other than a sign taped to the front window and a few packages under the desk. There are similar networks of places for travelers to stow their luggage.
This is pretty tangential to the proposal at hand. I guess there needs to be a decision about whether the proposed tagging scheme merely documents physical infrastructure for ordering and conducting the transaction for the sake of, or whether it’s also intended to facilitate those transactions by helping consumers find their way around a POI.
