Multi-story parking lot with no walls - is it a building?

If there is a multi-story parking lot that has no walls but only floors stacked on top of each other supported by steel beams, and as such does not give off an impression of an enclosed space, should it have a “building” tag or no?

Secondly, how to map the connections between different floors of the parking lot? The wiki help page Simple Indoor Tagging - OpenStreetMap Wiki only mentions stairs, escalators and elevators as connections between floors, but what about simply these ramps which cars use to travel between floors?

1 Like

I do map these as buildings, specifically building=parking. You’re right that it isn’t enclosed like most buildings, but neither are some other popular building=* values, such as building=carport and building=roof.

If you get into this level of detail, it gets intricate fast. I’m not sure if there are other popular ways of doing it, but here are some parking lots you might use as a model:

Some tips based on how I’ve been micromapping parking garages (others may have different styles):

  • Each entrance to the parking garage continues to be tagged amenity=parking_entrance but connects to a service road inside the garage. Remember that this tag is also for parking garage exits.
  • Inside the garage, each service road is tagged layer=*, and level=* for good measure.
  • I’ve been using indoor=yes and tunnel=building_passage on all the levels below the roof deck, but arguably these aren’t building passages, just covered.
  • The ramp between each level is tagged incline=up/down. In some parking garages, half of the ramp is marked as belonging to the lower floor and the other half is marked as the upper floor, so I split the ramp in two and assign a different level. But if it isn’t clear, I tag the whole ramp as one of the adjacent levels; just be internally consistent.
  • I try to keep the service roads tidy and aligned even when they overlap in reality, but it’s more important to only connect service roads where they physically connect. To avoid snapping service roads together in iD, hold down Alt (Option on a Mac) while adding a node.
  • Since it’s really difficult to keep track of the intricately connected ways, I start from the basement and work my way up to the roof deck.

Hope this helps!


Great answer, Minh, as always! I’d do some things differently though. Here’s where and why I divert:

You only use level=* for indoor-mapping, not layer=*. A layer > 1, by definition, requires the bridge=-tag and isn’t needed here, because routers and QC-tools do understand levels.


That is a contradiction. A tunnel=building_passage is by definition not indoors, because it’s a tunnel through the building with walls at all sides, which doesn’t make it indoors. I’d only use indoor=yes for these ways.

When a feature spans multiple levels, or even connects them (like a road or steps, even though roads aren’t explicitly mentioned, they work the same), the wiki suggests to use multiple levels like level=0;1 for a road connecting level 0 and 1 of a building. If it’s connecting more than just two levels, you can also use level=0-5

Besides these minor points, this is good advice. Getting started with indoor-tagging is a bit bumpy, but once you get the grip, it’s actually straightforward.


A tunnel=building_passage is by definition not indoors, because it’s a tunnel through the building with walls at all sides, which doesn’t make it indoors. I’d only use indoor=yes for these ways.

I only use indoor=yes if something is indoors.

I am not completely sure about the implications of “indoors” but had somehow assumed it means there is an enclosed space. For example if it is windy outside and you go indoors, I would think you would not feel the wind any more. A multistorey parking for me feels “outdoors”

layer=2 tunnel=yes can be entirely valid, layer >= 1 does not mean that something is over ground

using layer tag while mapping indoor features is useful and may be even needed in some pathological cases

Removing layer tags from Way: 20196693 | OpenStreetMap where it is an indoor feature would not help at all

I would add layer to Way: 236284062 | OpenStreetMap but it is at layer=0 level so implied value is good enough

1 Like

That is correct. I should have said: „anything with a layer != 0 requires tunnel=* or bridge=*, but there are exceptions even to these. I’m just saying it’s a good general rule of thumb to avoid using layer=* when you don’t have to use it.

No doubt about that, but in the case of a multi-storey parking building, I highly doubt that you need it. You know that you have to use layer=* together with level=* when you have a use-case for it :wink:

1 Like

OK, so if I understand correctly:

  • If it’s on an underground level: indoor=yes (without tunnel=*)
  • If it’s on the ground floor or above: tunnel=building_passage (without indoor=*)
  • If it’s on the roof deck: location=roof (with covered=yes if there’s an additional canopy)
  • If it’s on any of these levels but fully enclosed (such as a hallway leading to the restrooms): indoor=yes

Minh, I think you have got most of it, but likely not quite 100%. For example, whether covered=yes is or isn’t included on a location=roof could go either way, depending on the laziness or vigilance of the author / tagger: don’t make assumptions about the other tag if/as one of these tags is missing.

And, the where and how of indoor=yes is logically explained by you here (in a bit of a hand-wavy, not entirely clear, but intended-to-be-helpful way) but the geometry of how exactly that might be tagged / accomplished in actuality (in our map database) doesn’t seem easy to explain. Except in a “well, you know what I mean” kind of way, which is helpful for a first draft, but could use improvement.

But yes, all in all, I understand @dieterdriest’s ideas about indoor the same ways it seems all three of us do, too. And yes, layer and level must each be used carefully in places like large underground train stations (think Les Halles in Paris); the more subtle aspects of this are documented elsewhere.

With our words, we can often describe things more fully, but it is also often the case we can imagine exceptions. I have found it is not always the case we can describe things “always.” We get close, though, as you have done here. But rules are not always finite or completely describe everything.

Oh, I was speaking from the perspective of a mapper, not a data consumer. Getting data consumers to render parking garages correctly would probably require additional trial-and-error.

To elaborate, the “additional canopy” case is something like this solar panel covering the ramp leading up to the roof deck; the way would ideally be covered=yes:

I just drove past that solar panel not long ago, and yes, these solar roof panels are getting quite common.

The notion of indoor=yes and covered=yes for me goes like this:

  1. If I say „I’m in a building“ when being there, I use indoor=yes
  2. If I say „I’m under XXX“, then I use covered=yes
  3. If I say „I’m on top of XXX“, then I use outdoor=yes, even though my coordinates are enclosed by a building.

I know that this isn’t very scientific, but sometimes, it doesn’t have to be. If it’s just a roof, I’d never say „I’m in the roof“, but „under the roof“. But for a car park , I’d say „I’m in the car park“, no matter if it has walls or not. „Under the car park“ would feel like being in a tunnel that goes under it. building_passage: even though I am in the building passage, I am not in the building and I would therefore not consider myself to be indoors (relatively to the building the tunnel goes through, that is).


But for a car park , I’d say „I’m in the car park“, no matter if it has walls or not.

I agree, but unless it is underground, I would typically not consider it to be „inside“, as it will be as cold and windy as outside.

1 Like