I made this tunnel here, but it looks a bit strange: (click to enlarge). The orange road seems to extend past the little black tunnel marks on both sides of the tunnel. Did I do something wrong or is it normal? I've seen other tunnels where the road stops right at the tunnel mark, like in the example on the Tunnel page. Mtcv 16:21, 2 July 2007 (BST)

Perhaps because the road is not a contiguous way? Renderers prefer ways to be in one piece, without branching segments. The way in you example consists of segments on both sides of the tunnel; possibly the renderer gets confused by that. I've cut the way in two; let's see if that improves things. Eugene van der Pijll 18:40, 2 July 2007 (BST)

I don't think it's working. I didn't think it would make a difference anyway, because I made another tunnel in the same way (non-contiguous) here and there it looks ok. On the other hand, I made yet another tunnel here, with three ways (one before, one tunnel and one after) and there it looks strange again. I guess this is just normal random behaviour ;-) . Mtcv 16:14, 3 July 2007 (BST)

You need to use layer 1 for the railroad. But that doesn't look like a tunnel to me, it looks more like a bridge going over that road.
--Skratz 13:36, 1 October 2008 (UTC)

Shipping tunnel

Hi, i'am living in germany and want to tag the only shipping tunnel in our country (see also http://en.wikipedia.org/wiki/Weilburg and http://www.openstreetmap.de/karte.html?zoom=17&lat=50.48242&lon=8.26603&layers=B0). Do i have to tag the part of the river with level -1 ?

Therefore we dont use a "layer"-attribute.

Tunnel with layer=-1 is like animal=black horse+color=black...

--Markus 11:31, 3 September 2008 (UTC)

Discussion at Talk:Key:layer#Layer. --Eimai 12:37, 3 September 2008 (UTC)

Ways under a building

I am mapping Barcelona, where some streets go under the houses. Then, I take the part where the street is under the house and tag it as tunnel. The problem is: When this street joins an other, I'm joining featuers at different levels. Is this right?

An example could be here: http://www.openstreetmap.org/?lat=41.381301&lon=2.171508&zoom=18&layers=B000FTF

Where the end of the tunnel connects to only one other way, the ways can have different layers. The way with the tunnel tag should start at the location where the wall is. Example with the location you specified: you could/should add a new way with highway=pedestrian to connect this way to the Carrer Hospital (if it's possible to walk from that pedestrian way to that road, which I assume to be possible). Likewise for other highways in tunnel: a short way not in tunnel connects to the crossing street, because the tunnel does not end at the intersection midpoint but before that. Alv 13:31, 29 July 2009 (UTC)

Tunnel vs. bridge

Quote: Language sometimes misleads us. At least in Swedish, the word "tunnel" is used for two different things:

The latter is best represented in the OpenStreetMap as a bridge on the top route, even if most people wouldn't refer to that crossing as a bridge. The difference is especially noticable when the two routes are not perpendicular. For a tunnel, the OSM decoration on the lower route. For a bridge, the OSM decoration is on the upper route. If a road cuts under a railroad at 70° angle, this is better rendered as railroad bridge above the road, than as a road tunnel underneath the railroad.

We don't tag for renderes. A tunnel should be tagged as tunnel and a bridge als bridge! It is not only a problem in swedish languages, that people mix up tunnel and bridges if there is an underbridge/underpass/undercrossing. I think some pictures should explain the difference. --Langläufer 16:58, 4 September 2009 (UTC)

I'd say if the street over the tunnel has limitation in weight for example it is in every case a bridge. And if the tunnel has limitations( e.g. height), it is a tunnel. So you can see that I think that there is no "either or". Use both if you can't decide! --westfa 16:58, 15 November 2009 (UTC)

This is not a question of the limitations. You can put the limitations without any tunnel or bride tag at the ways. And you can have limitations for both street, upper and lower at the same time - but it should not be tagget as tunnel and bridge at once. --Langläufer 07:06, 16 November 2009 (UTC)

This is not a problem of Swedish language, this is a problem of common natural language. In natural languages, meaning of words is not as strict and clear, as in technical (scientific) language, where words are actually terms with strict definitions. I OSM, we don't use natural language, we use terms. Bridges and tunnels are subjects of structural engineering science, and in engineering, tunnel is a man-made structure (passage way), dug (or constructed in other way) through surrounding substance, such as earth, rock and so on (including water). So, if this structure is surround by earth or rock, it's a tunnel, not just a passage under something like bridge or any other structure. If there is a building above the street, standing on columns or other support structures, it doesn't turn this street into a tunnel. it just makes it covered. --BushmanK (talk) 22:21, 6 June 2016 (UTC)

I think we should distinguish between street name and tunnel name. hence a single name-tag is insufficient since street and structure (e.g tunnel or bridge) can have different names. is the usage of a namespace advisable? e.g. name=foo (name of the street) vs. tunnel:name=bar (name of the tunnel in conjunction with the tunnel tag)? please comment! --Marc 12:02, 29 December 2009 (UTC)

Wouldn't that be loc_name=*? A name for a tunnel seems quite local. --goldfndr 03:36, 30 December 2009 (UTC)
. local? I wouldn't bet on it. the local name should be used when it differs from the original name. doesn't make much sense to alienate tags: the problem itself isn't solved by that. --Marc 08:19, 30 December 2009 (UTC)

Could you provide an example of a tunnel on which loc_name=* would be inappropriate? Better yet, an example of a street section (way) that has a name, a local name, and a tunnel name? --goldfndr 16:51, 31 December 2009 (UTC)

Well I haven't too. The fact that it could happen should be enough to look for a better, bullet proof solution. But if you want an example: take the Gotthard road tunnel in Switzerland. you got 3 names for each national language, an english name, local names (like "erste Röhre", "Gotthardröhre" and many more) and you have the A2 motorway going through the tunnel, also known as "Gotthardautobahn", "Nord-Süd-Achse" (many national, local and alternative names). Or take the old Elbtunnel in Hamburg: Sankt Pauli-Elbtunnel (official name), Alter Elbtunnel (currently used as old_name), Radkappenkiller (definitely a local name) etc..You can look for local names on almost any bigger object. You and I might not know them, but locals do (hence the name). And they can apply to the highway and the tunnel and be different from each other. Using the loc_name=* for the tunnel and name=*for the corresponding highway section would be an unnecessary constriction. --Marc 09:03, 1 January 2010 (UTC)

One option is to use relations for the naming, i.e. one relation for the autobahn with its names, and another relation for the tunnel with its names. This way you can manage name=*+old_name=*+official_name=*+loc_name=*+alt_name=*+name:fr=*+name:de=*+name:en=*+name:it=* and probably many more for both objects without conflicts. This will also leave it to the renderer if the highway name or the tunnel name is to be rendered, and makes both the highway name and the tunnel name to be searchable. --Skippern 12:13, 1 January 2010 (UTC)

yes this would be an option. but what is the benefit over using the namespace approach (tunnel=yes + tunnel:name=..., tunnel:description..., can be expanded to virtually any tag, e.g. if a tunnel / bridge / access restriction / the filling pump for diesel on a fuel station has a specific name or description or fixme-tag and so on). I'm just not that convinced about using relations to somehow fix tag scheme shortcomings. And therefore I'm searching a generic approach that fits any tag combination, even if some of them don't seem reasonable. the relation approach is accurate but adds - in my opinion - a lot of overhead and complexity without providing a generic and simple approach to the problem (which extends fairly beyond the tunnel naming problem). and especially when looking at things like the fixme tag it would be great to use a namespace approach, e.g. for something like opening_hours:fixme=resurvey instead of just a simple fixme tag. and this concept should be extended to tags like name, comments, notes and so on. it makes things just a lot easier without using relations or newly invented tags. that was the idea I had in mind. therefore I might like the relation approach but it doesn't solve the main problem I currently see with OSM tagging scheme. (sorry I'm not a native english speaker so it's fairly hard to express myself) --Marc 12:30, 1 January 2010 (UTC)

If we are to head in and prefix name for everything, building:name, highway:name, place:name, waterway:name, bridge:name, tunnel:name, than we would make it extremely difficult to make rendering and search software, maybe even routing software, as they would need to filter *:name on top of how they do it today. Therefor relations are a cleaner approach to it. Than your fixme problem is different, I agree that a fixme tag could be prefixed to specify what needs fixing, and as far as I know, only keepright and maplint need to check for these. I see no problem in tagging pumps:fixme=check octane numbers, do they have bio diesel here? or other variants of fixme, this way it can be easier to search for those interested in fixing a specific problem, i.e. have a PD list of gas stations that sells bio diesel. But all of this are derailing off the problem with tunnel names. I suggest relation to solve that. --Skippern 14:07, 2 January 2010 (UTC)

No, I don't want to replace every name tag with a prefix:name. so the normal name tags remain: name=* is used for the entity itself. there is no need for prefexing highway, place, waterway or building names. prefix:name=* is just used for naming specific tags of an entity (naming an access restriction of a street, the tunnel of a street and so on). It's a generic proposal that can be used for the tunnel and every other naming problem. so there is no need to change anything in current software implementations: the normal main name tag remains. and besides that: filtering for prefixed name tags or searching and handling relations makes no difference. it's always an additional step you have to make to extract the tunnel name. Do you have any information showing the performance differences between using a relation vs. extracting the name from an existing tag? that would be interesting. --Marc 07:26, 3 January 2010 (UTC)

I cannot show you anything related to software performance, as I have no working rendering, searching or routing software to test on, but I can see it from my experiences as a mapper. I have used relations to groupe together long highways, where I have put both name and ref tags in the relations, while I have omitted this on some segments of complex intersections on the same highway. Also some parts of such highways passing through cities have local street names in addition to the highway name. Here I have used the local street names in the name tag and left the highway name in the relation. This can also be done for tunnels and bridges, I would then use the tunnel or bridge name on the road segment, and leave the highway name in the relation. I do not know if this is righter, it's the way I do it and will continue to do it. --Skippern 12:35, 3 January 2010 (UTC)

I think Marcs proposal: "tunnel:name=* or name:tunnel=*" is verry good. It could be also used for bridges or some other things. Using relations ars not comfortable, because the name-key indicates only the name of the highway/railway/waterway. Example: If a highway with a tunnel is tagged by "name=Alpha Street", is this the name of the tunnel or street? (-> name is from highway/railway and name:tunnel is from tunnel) So we have to diskus which is better, XXX:name=* or name:XXX=*. In the tagwatch both is used. Than one of the important part is, write it into the wiki. -- MasiMaster 00:10, 27 January 2012 (UTC)

Tunnel vs. underpass, add underpass=yes tag?

In the wiki page, tunnel is first described by: "The tunnel tag is used to map ways that runs through an underground passage."

Then however, in the third paragraph, it appears the "underground" requirement is dropped, by classifying underpassesas tunnels: "At an undercrossing/underpass you have to decide on the basis of the construction if you are in a tunnel or under a bridge. The ramps down to the underpass are not part of the tunnel. These ramps can be tagged as cutting=yes."

In Wikipedia, http://en.wikipedia.org/wiki/Tunnel , theres a topic "Usage limitations":

"A tunnel is relatively long and narrow; in general the length is more (usually much more) than twice the diameter. Some hold a tunnel to be at least 0.160 kilometres (0.10 mi) long and call shorter passageways by such terms as an "underpass" or a "chute". For example, the underpass beneath Yahata Station in Kitakyushu, Japan is 0.130 km long (0.081 mi) and so might not be considered a tunnel."

Typical tunnel-tagged underpasses go under a road or a kind of bridge, and are not really undergrand. I think it would make sense to introduce "underpass=yes" for the underpasses (used with the layer tag), and reserve "tunnel=yes" for the cases where the way really runs through an underground passage.

This would make navigators better able to give instructions. For example, the GpsMid navigator currently instructs to "into the tunnel" for underpasses commonly marked with tunnel=yes - even when they only go under a road construction, not really underground.

Anyway think alike? Anyone of those possibly thinking alike familiar with how to set up a new tag proposal for Key:underpass? --Jkp 10:52, 4 October 2010 (BST)

there is no common international definition for tunnel. Nether heard of that 160 meter limit. Only common is, that it leads through underground. So it becomes not more simple to differentiate between tunnel, underpass and bridge. An underpass is every way, that goes under an other way. That says nothing about construction. --Langläufer 18:39, 4 October 2010 (BST)

I'm thinking part of that issue was Langläufer incorporating my cutting mention into a paragraph rather than (as it's a separate topic) making it a separate paragraph. I've separated it out, and made a similar edit at bridge.

I concur that any "tunnel-tagged underpasses" that "are not really underground" should not have a tunnel tag (and, also, should be layer=0). But I'm curious for an example in which the road above is not a "kind of bridge", as I'm wondering how that's physically possible. As for underpass=yes, I'm imagining that as cutting=yes, with bridge=yes for the layer>0 roads above, but a counterexample would be helpful. But if there was an underpass=yes, wouldn't it only be a node (carefully placed to be an "intersection" of the two highways) and not a way? Is there a rendering or other analysis advantage, and if so would the same argument be used for an overpass=yes tag or an expansion to Proposed features/Junction? --goldfndr 14:47, 5 October 2010 (BST)

layer=0 is the default for all elements without the tag layer. So forget it. --Pieren 15:31, 5 October 2010 (BST)

Could it be that tunnel=underpass would be the best choice  ? It is quite often that general roads are lifted up from the surrounding landscape somewhat so that when paths or other roads cross under the road, there is neither a traditional tunnel nor a bridge, but some kind of hybrid ? Referring to Proposed_features/building_passage where we see that tunnel=avalanche_protector etc was approved. As of today tunnel=underpass has been used 20 times. [1]. We also have 34 instances of key:underpass=yes [2] --MortenLange (talk) 19:34, 14 June 2016 (UTC)

As an example I seriously doubt many of all those "tunnels" seen here in the Netherlands [3] are real tunnels, rather than underpasses. It will be of value to be able to find real tunnels for cycling and walking on OSM.

OSMs "tunnel or bridge" scheme is unrealistic in 90% of cases. Many of those are grade separated crossings which are a mix of a tunnel and bridge building with two ways on different levels. We could develop a new tagging scheme for those but I don't see a benefit in those simple cases. RicoZ (talk) 13:53, 16 June 2016 (UTC)

building passage

The voting on new tunnel values has started: https://wiki.openstreetmap.org/wiki/Proposed_features/building_passage --Flaimo 08:19, 22 November 2012 (UTC)

Tunnels not rendered

Some tunnels on A14 motorway in Italy are not rendered, like this one: http://www.openstreetmap.org/?lat=43.922901&lon=12.81185&zoom=18&layers=M , or this one also: http://www.openstreetmap.org/?lat=43.97839&lon=12.65771&zoom=17&layers=M . Does someone know why? --Gspinoza 18:18, 19 December 2012 (UTC)

Simple, they just needed to have the /dirty command called to render them. Seems like when they were last edited, it must have been during an rendering outage. Thus, when the /dirty command is called, they get re-rendered and the tunnel shows up properly. -- rickmastfan67 14:19, 20 December 2012 (UTC)

I found that A14 relation had a tag highway=motorway which wasn't supposed to be there. Other Italian motorways had it (A4 and A1) and none of them showed tunnels. I removed the tags and tunnels reappeared on A4 but not on the others. I never encountered the /dirty command, and I don't know how to use it. --Gspinoza 16:24, 20 December 2012 (UTC)

You need to get the tile image link, and then add "/dirty" to the end of it. See the Slippy Map page for more info about this. -- rickmastfan67 03:42, 1 January 2013 (UTC)

Structure on the end of tunnel to cover sun and avoid bright blindness

How would you map these structures often used in tunnels to prevent drivers/train conductors from being blinded by the sun? Check pics: 1 - 2 - 3 - 4 - 5. Currently I've been using building=yes, but some mappers might see that as tagging for the renderer. --Nighto (talk) 18:16, 5 May 2014 (UTC)

Depends on what it looks like. Look at key:covered if it has something that you could use, else decide on some new tunnel or covered sub-tag and let us know. RicoZ (talk) 11:35, 13 May 2014 (UTC)

tunnel with partially open-air segments?

Some tunnels have segments that are uncovered, among other things to let air circulate. For example, in [1] those segments are marked as being surrounded by a retaining wall (google earth view in [2]) This situation is ambiguous. On the one hand, these segments are partially or wholly uncovered at the top, so it would be plausible to remove the tunnel tag and leave layer=-1; on the other hand, doing that would create several short non-tunnel segments that render badly (it preferable to render the tunnel continuously) and would be misleading, since they are in fact part of the tunnel and not completely open air (like a cutting). What is the best way to tag this?

[1] https://www.openstreetmap.org/#map=18/38.74227/-9.14697 [2] https://www.google.co.uk/maps/place/Lisboa,+email@example.com,-9.1470302,321m/data=!3m1!1e3!4m2!3m1!1s0xd19331a61e4f33b:0x400ebbde49036d0
[null, {"document_url": "https://wiki.openstreetmap.org/wiki/Talk:Key:tunnel", "unformatted_src": "/w/images/thumb/f/fc/Strangetunnel.png/300px-Strangetunnel.png", "src": "https://wiki.openstreetmap.org/w/images/thumb/f/fc/Strangetunnel.png/300px-Strangetunnel.png", "formatted_filename": "px Strangetunnel", "alt_text": "Strangetunnel.png", "rendered_width": 300, "rendered_height": 213}, null]