How best to tag drive-through elements?

Help and support
1

I am looking to update a highway:service + service:drive-through with details on its way. Specifically, I am looking how best to tag the following elements after finding little guidance on the wiki:

  • Speaker post
  • Flat-top canopy
  • Clearance bar (and it’s height)
  • Directional sign (such as “Drive Through [right arrow]”)
  • Pick-up awning (if we are to map what is on the ground)
  • Pick-up window attached to side of a building (tag & location)

Finally, is it better to mark these items as a separate node or as a node on a way? Some things, like a clearance bar or speaker box may be useful for routers to alert drivers to so I can see some benefit to adding to the way but would like community input.

Thank you!

2 Likes
2

Replying in case anyone has a solution to share.

3

Fantastic. :slight_smile:

This info really helps around fast food restaurants or banks.

Personally, I just mark:

  • highway=service
  • service=drive-through
  • oneway=yes

From there, if there is some sort of awning (or height bar) in the drivethrough, you can add optional:

  • maxheight
    • (OSM Wiki)
    • (To be quick, I add maxheight on the whole way.)

and I even add:

  • surface
    • Sometimes the drivethroughs are concrete instead of asphalt.

Clearance Bar

You can add a little node on the way with:

  • barrier=height_restrictor

Note: Put it exactly where the drive-through lane goes under the bar.

Flat-top Canopy + Awning

Personally, I don’t draw it as a separate thing. To be quick, I just have the awning drawn as part of the entire building.

As I’m drawing the drivethrough lane, I then do this:

1. Add 1 node right BEFORE the awning + 1 node right AFTER.

2. Attach the rest of the drivethrough like any other road.

3. Split the way.

In ID, you can do that by:

  • Shift+Left-Click on the 2 nodes (before/after awning)
  • Press X.
    • Or you can also Right-Click > Split
      • (The icon looks like scissors.)

4. Then tag the little piece under the awning as:

  • covered=yes

5. Then, I:

  • Mark the actual building as layer=1
    • since it will be “above” the little drivethrough road.

So you’ll ultimately have 3 separate drive-through pieces:

  1. Driving in to place your order.
    • Going through and towards the pick-up window.
  2. Under the awning.
    • Has covered=yes, because it’s under a roof.
  3. Driving away.
    • So this attaches back to the parking lot/aisle and leads you out.

Side Note 1: And for that little piece of road under the roof, make sure you use:

  • covered=yes

and not the accidental:

  • tunnel=building_passage
    • This is for tunnels going through the middle of buildings.

That’s an extremely common error I see.

Side Note 2: While you are there, instead of having the generic building=yes…

You may also want to tag the actual building as:

  • building=retail
    • If fast food.
  • building=bank
    • If it’s a bank.

This helps incrementally make the map a little better. :slight_smile:

4 Likes
4

That’s awesome, thanks so much for this guidance, any idea on the other elements? And would a detached canopy around a menu board / speaker box be a roof?

5

Can you show a photo or screenshot of exactly what you mean? (I think that’ll make it easier for others to give input too.)

I’m suspecting it’ll just not be drawn at all… or drawn/tagged as a normal building=roof.

No problem. And no, not really. I don’t go micromapping to that level of detail.

I mostly just draw the parking lots + parking aisles + drivethroughs, add any missing business info (like website/phone), then go moving on.

1 Like
6

Something like these canopies were what I was thinking. It gives some relief from light rain and sun to the driver speaking into the speaker box and the speaker box itself sometimes.

7

Oh. Something like that, I wouldn’t even bother drawing.

(If someone does eventually come along to mention a specialized tag for these “speakers/microphones” or these “outdoor menus”… they’d just be a little node anyway.)

You could just add covered=yes on that Node then, similar to how you might have “covered bicycle parking” to protect from the rain.

See OSM Wiki for “covered”.

I thought you may have been talking about something more substantial, like the outdoor ordering at Sonic:

SONICDocks
SONICDocks1600×1067 241 KB

8

Thanks again for the help. All the sonics in my area I’ve tagged as a roof with parking partially under said roof. I should go and add the “covered=partial” tag now that I think of it to the parking.

9

Now hung up on speaker boxes specifically and menu boards.

Speaker boxes are a post, that has a speaker, and a microphone, used as a form of 2 way radio, in a commercial setting. Each of these attributes has an associated tag but mixing them seems like mistagging.

Likewise, a menu board is an information board, but a commercial one, and may also contain advertisements, as well as optionally be lit or electronic in nature. Again, each can be tagged but seems like mistagging for such a common feature.

Pinging @Minh_Nguyen and @Kovoschiz as they’ve helped me in the past.

10

First of all, this is very minute detail, so the stakes are very low. You don’t need to worry very much about conformity unless you’re planning an bulk import of some sort. It seems kind of pedantic to me, but at least it’s more topical for OSM than trying to literally encode a restaurant menu as a series of tags like lunch:menu:course:soup=yes.

This McDonald’s drive-through menu is tagged as a tourism=information information=board board_type=menu. The other two occurrences of this tag combination are for menus in front of fancy restaurants. There’s a recent proposal to remove the requirement for tourism=information, so that it would just be information=board board_type=menu.

I’ve never seen anyone attempt to micromap the two-way radio at the ordering station, but it might be useful to approach it by analogy with vending machines and ATMs. For accessibility reasons, there’s a well-established speech_output=* key, and by analogy there’s a documented speech_input=* key that apparently fell out of use. If the communication device is integrated into the menu, you could add these tags to the menu node. Other than that, maybe you could just coin a new tag specifically for the speaker post. Maybe man_made=speaker (not to be confused with man_made=loudspeaker)?

Mappers sometimes ask how to tag a restaurant’s walk-up window, since there’s no drive-through in that case. The window=* key is well established and supported by some hyperrealistic 3D renderers. These renderers don’t really care about the value, but you could set it to something descriptive to scratch that itch. walk-up, drive_through, and drive-up appear a few times. For your drive-through drive-up window, I’d suggest drive-through for consistency with service=drive-through.

1 Like
11

A lot to go through there, thanks so much. I will say my first thought was a checkers which not only has 2 drive throughs but also 2 walk up windows as well as the aforementioned menu boards and speaker boxes but has the complexity of one of the drive throughs only accessible to the passenger! A micromappers worst nightmare!

IMG_1265
IMG_12651280×960 634 KB

12

Doesn’t sound so special to me. :wink:

1 Like
13

Anarchy! In OSM!

14

=intercom would include both =speaker and =microphone (?), and be usable for security or any other purposes amenity=intercom | Tags | OpenStreetMap Taginfo
At least the term is used by some in the industry, and some common language

Not “intercom”, but there was a decade-old question that’s related to =border_crossing without the barrier= Talk:Tag:amenity=telephone - OpenStreetMap Wiki
A problem with this is how to handle local “telecom” that’s emergency=phone

2 Likes