I recently noticed some service roads mapped in my area that didn’t look much like roads on aerial imagery. A note from the original mapper said that the surface was grass but that the ground was reinforced with a plastic grid so it could support heavy vehicles. A site inspection confirmed this as the plastic grid was visible in a few spots.
This sort of plastic grid system seems to be similar to the permeable concrete pavers that we tag surface=grass_paver but with the potential to be far less visible. Across most of the surface area, the plastic grid was not visible at all and it just looked like a grassy area. Here are two views from either end.
The curb cut is an indicator of intent to allow vehicle access in an emergency, and with a keen eye one can see that the grade has been leveled so vehicles wouldn’t be driving on a slope. Otherwise, this supposed service road blends right in with its grassy surroundings.
These spots stand out a bit more from the rest of the grassy area, but they still aren’t very recognizable as roads. The last photo probably comes the closest as the grass is the most worn away there and a few tire marks are visible. However, this is only really right at the beginning and grass is thick just beyond.
These fire lanes are currently tagged highway=service + service=emergency_access. The emergency access part certainly fits, but I can’t help feeling like highway=service does not. I’ve looked at some other maps of the area and none of them display these fire lanes as roads (or at all), not even the map on the website of the apartment complex. It feels to me like a new primary feature tag would be best for this sort of emergency access lane that is barely noticeable to a casual observer. Or maybe there already is one that I’m not aware of? What do you think?
Any idea if this is a common way of surfacing a fire lane? If it’s rarer than, say, a BRT lane (highway=busway), I’m inclined to tolerate highway=service as an imperfect but explainable feature tag. Besides surface=grass_paver or something more specific, I think you’d have to add some sort of visibility=*, at least so that another mapper doesn’t come along and delete the path without having seen it up close.
service=emergency_access is already an indicator that these are not “classic” service roads. I also map such emergency access roads with highway=service + service=emergency_access, because imho this is exactly what this tagging is for (an exclusive way for emergency services to reach e.g. a building). surface=grass/grass_paver/... further limits the character of these ways.
I see no need for a new tag but rather the data users’ responsibility to make use of the existing tags (e.g. to not route over and render such roads discreetly - except on rescue maps).
There was some discussion about this type of surface strengthenning in a recent dicussion about beach access mats (note there are two types of surface in that discussion).
Probably not everybody since there is plenty of space in the paved parking lots right next to the buildings but some people might use it as a shortcut. Most likely the curb cuts are frequently used by maintenance vehicles like lawn mowing equipment.
The idea that road_visibility=no could accurately describe these fire lanes much as trail_visilbity=no accurately describes pathless hiking routes has crossed my mind. However, I am holding out hope that the OSM community can learn from that debacle and realize that mapping a nearly invisible thing with the same primary tag as a related visible thing makes the data harder to work with.
It seems like fire lanes sometimes only really exist as a regulation stating that space around a building must be kept clear so a vehicle could drive there if necessary. This was the case at an apartment building I used to live in. Some ground floor residents wanted to install decks or privacy fences in their back yards, but were not allowed to because the space was a fire lane that had to be kept open. It had no on the ground indications of being a fire lane. It would be surprising to see this backyard space showing up as a service road on a map.
Do the ones you’ve mapped blend right into the surrounding landscape like the photos I posted, or do they have a visible surface difference that sets them apart? Permeable concrete pavers like these would be much more visible for example.
Emergency access “corridors” like the ones on your photos are very common here in my area (Berlin, Germany). Looking like grass, sometimes with flexible poles on the edges, usually with a “firefighters access” sign and lowered kerb where this grassy stripe meets the road. If you take a closer look then you might see this supporting “grid structure” to prevent fire engines from sinking in to the ground.
I think I often tagged them with surface=grass, but yes - maybe there is lack of a better fitting value here somewhere between grass and grass_paver.
Is there any debate about where the fire lane leads, or even about the width of the fire lane? The fire lane’s visibility tag becomes a hint for photorealistic renderers and for fellow mappers, but the fire lane’s presence on a map is more about the potential movement of vehicles than about physical construction. To me, an analogous situation would be a pedestrian crossing where the curb cuts are apparent, but the markings blend into the road pavement enough that you’d have to rely on street-level imagery or a field survey to detect them.
If I had to retag this as something other then a roadway, I might look at emergency=* as a thematic key, but that’s problematic because the same key is also commonly used as an access key – in combination with service=emergency_access, no less.
These access corridors are common in my country as well (USA). I believe they are often required by building codes. What is uncommon is to see them displayed on a map. I could imagine a specialized emergency services map showing these corridors, but they would likely be shown in a different style than emergency access roads. The distinction being an actual visible roadway vs an unobstructed area across a lawn that is wide enough for emergency vehicles but unrecognizable as a road. I’m sure in Germany these are all very well signed so their existence and purpose is clear, but here in the USA signage is often not present and passersby would not notice anything other than a lawn.
The unfortunate thing about including these corridors under highway=service is that in order for a general-purpose map to display only actual service roads (those with a visible physical roadway) they must somehow exclude emergency access corridors. They could exclude any highway=service + service=emergency_access but that will also exclude emergency access roads that do have visible physical roadways. They could exclude any highway=service + surface=grass but relying on a surface tag to distinguish a different feature class feels sub-optimal to me (is the surface always grass?).
To be honest, personally I wouldn’t map these in OSM at all.
I can drive a car over a grassy backyard, but that doesn’t make it a highway=service + service=driveway, even if the grass begins to wear a bit in one spot.
Mapping these reminds me a bit of the objections to mapping railway=abandonedrailway=razed. It’s out of scope for OSM. Much like with railway=razed, the biggest difficulty would be with keeping it out of OSM when people who recognize them (or find them on specialized maps) add them.
If you must, map it as an area with surface=grass_paver because that’s what can be seen on the ground.
I also would not map these in OSM, but I am trying to decide what to do with some that another mapper has added. Even though I have no interest in mapping these access corridors, they do seem verifiable enough to be mapped as something. I just don’t think they should be mapped as roads. They are basically just areas of a lawn that are required to be kept free of obstructions so a fire truck could get close to the building if need be. This eventuality may never happen.
I don’t wish to delete another mapper’s contribution, so I am searching for alternative tagging. Key: fire_path - OpenStreetMap Wiki seems to fit. Perhaps I will use that.
