[RFC] Refining `service=alley` with 2 new service tags - Proposal

General talk Tagging general discussion
,
1

The current use of service=alley has been a longstanding source of conflicts among mappers, with various discussions around, including a recent introduction a new highway=alleyway proposal to address this.

While the proposed highway=alleyway tag aims to cover streets too narrow for some automobiles, it faces a few significant issues:

  • The name conflicts with the established service=alley usage.
  • It doesn’t address the conflicting use of back and front access roads that are wide enough for automobiles.
  • Introducing a new tag would hide existing data from maps, and mappers may be hesitant to adopt it until most renderers and routers support it.

Instead, I propose a more gradual approach by proposing two new service=utility and service=lane sub-tags. This would simplify the transition from service=alley without the need for a completely new top-level tag.

Note: there may be objections that some of the use-cases described below don’t fit the traditional highway=service definition (similarly to service=busway topic), but since these are already in use worldwide, adopting new service=* values could pave the way for a smoother transition to a dedicated highway tag in the future.

Use-cases

Currently, service=alley is applied to three distinct scenarios:

  1. Backstreet Utility Access

    Service lanes that provide rear access to utility poles, fire escapes, garages, delivery zones, and garbage collection points. Commonly referred to as “alleys” in North America.

  2. Narrow Urban Streets Between Buildings

    These narrow streets serve slow-moving local traffic and are often more pedestrian-friendly than typical roads. Provide front-access to homes and businesses. Found in medieval European cities (e.g., “Gasse” in Germany).

    Alternative Tagging: highway=residential

  3. Narrow Urban Paths

    Paths too narrow for standard 4-wheel vehicles, primarily used by motorcycles, and branching off of main roads. Common in dense urban areas in Asia, where motorcycles are widely and legally used.

    Alternative Tagging: highway=path + motorcycle=yes, highway=footway + motorcycle=yes

Proposal

By refining service=alley into more specific categories, we can better represent the variety of narrow ways without compromising existing data or usability.

  • Introduce service=utility for use-case 1, implying motor_vehicle=yes.
  • Keep service=alley for use-case 2, implying motor_vehicle=yes.
  • Introduce service=lane for use-case 3, implying motor_vehicle=no and motorcycle=yes.

What are your thoughts?

Reading resources

1 Like
2

I have some issues with widening the usage of service.

Originally service has been the tag for roads which are not part of the public road network. E.g. mostly private property but in any case somehow restricted in usage or ownership.

This makes a lot of sense to have this differentiation because without any more processing one could argue that thru traffic should never traverse a service road which is in nearly all cases an error.

With the further extension of service=* tags we weaken or dilute this assumption which i am not a fan of.

The next thing is that a service/alley or service/utility is just some “small residential road” probably not suitable for 2 track vehicles.

Up to now physical appearance is not part of road classification and is contained in its own tags which describe those physical attributes e.g. “width”, “smoothness”, “lit”, “surface” etc.

We made this mistake already with overloading “tracktype” implying physical appearance and we should not repeat that.

If its a physical limitation for narrow vehicles we should name it “width” and not invent a new tag.

Flo

3 Likes
3

Not at all. I believe this is a complete misconception. There’s absolutely no mention of a non-public road network requirement anywhere on the wiki page, from its creation all the way up until service=alley was added as a ‘narrow road or path between properties’ in this update. I think it was added much later and can be considered controversial.

A road that isn’t part of the public street network should be tagged with access=private or other appropriate access values.

highway=residential and highway=track aren’t meant for through traffic either, so I don’t get why there’s this specific expectation for only highway=service. And no, in most cases service=alley (use-cases 1 + 2) is wide enough for cars and often just provides access to shops and businesses.

Roads should be classified by their function or usage, not just their physical features. The distinctions in the proposal focus on usage like ‘rear access to utilities,’ ‘slow-moving traffic that’s often more pedestrian-friendly,’ or ‘mainly used by motorcycles’…

4

How “not at all”? There is the description of “Generally for access to a building” etc from start. When it is read together with other cases listed, it can be seen it doesn’t significantly mean a “public” “street”.
The question about functionality is that narrowness can be a characteristics, yet doesn’t need to be a definition. The focus can be a lower class of roads than =residential , or a less important type of =residential . For example, a =service is usually not very wide, but that’s not part of the definition. The physical condition can simply form the most common and standard case.
For service= :

  • =utility : Doesn’t cover “fire escapes, garages, delivery zones, and garbage collection points” , except for utility=waste in OSM meaning that originated from maximizing marker= use as motivated by vacuum trash collection. This appears it can be used for any =service road related to utility= , not only side or rear access.
  • =alley : Even if =service is used, keeping it only prolongs the confusion. You can’t distinguish which one of them has been changed or verified either. Still need a new replacement.
  • =lane : Unclear difference with “alley” from the word. A “lane” in the narrow road meaning is still compatible with car use.
2 Likes
5

Great point about focusing on the lower importance aspect!

That’s not how I see it. The phrase “narrow road or path between properties” added in 2010 doesn’t suggest non-public access. If it was really all about non-public access, why wasn’t it mentioned in the wiki earlier?

I thought it might be helpful to broaden the scope. Otherwise, I was considering service=backstreet.

That’s not really a problem. We’ve seen similar cases like highway=via_ferrata/ladder being tagged before highway=path/steps, and we didn’t need to replace highway=path/steps. Highway classifications keep changing all the time (e.g., residential <> unclassified). How do you know which are verified and correct? By educating mappers on new tags (iD Presets, changeset comments).

That’s a tricky one. I’m open to any suggestions. I’ve hinted at “highway=motorcycleway” before, but some people argued that tag names shouldn’t be based on access tags (hello cycleway and footway).

6

You again conflate public access rights with public network.

“Public network” means that a government entity – country, state, province, municipality, whoever – is responsible for ownership and maintenance of the road, and kind of guarantees that it shall be accessible to the designated transport mode. But your downtown pedestrian shopping street is also part of the public network and is managed by the local government, yet it has motor_vehicle=no spelled out or implied by highway=pedestrian.

“Not part of the public network” means simply that – the road’s status is not of universal public concern, but in itself it implies nothing about access rights. Let’s take parking entrances/driveways as an example – the parking may be operated by a municipal corporation (and therefore be access=yes), a shopping mall operator (access=customers) or a company which reserved for its employees and guests (access=private). But lacking ownership information, all of those will still be a highway=service: not part of the public road network. I would argue that the default access for all highway=service is permissive: you can probably drive your car there, but only with good reason, and the access can be rescinded at any time.

3 Likes
7

It would be better to subclass alleys with alley=whatever if there are several subtypes, rather than attempting to change a tag with 1.7M usages. I think the current usage of service=alley is fine, and I would oppose efforts to move them to other tags.

6 Likes
8

You are right, yet I still don’t see how the initial wiki history points that highway=service “the tag for roads which are not part of the public road network”. But that discussion can be continued somewhere else.

9

Just like path, the alley case demonstrates the perils of selecting a common English word with a wide range of meanings as a tag value: most people will use tag for the purpose they are most familiar width, or just use the preset (which is in iD named just “Alley”). However, we choose it to denote just a narrow range of possible meanings. As the result, the tag ends up inevitably skunked.

We avoided the trap with road and street, the former being rarely used and the latter not at all. I don’t see an easy way out of alley – it would be best, if unrealistic, to retire it altogether, and invent 3-4 new tags instead. Not going to happen.

3 Likes
10

It’s not “skunked”, it has a well-understood meaning, or at least a pretty narrow set of well-understood meanings. It’s been used millions of times. Changing it is impossible, and it’s a waste of everyone’s time to suggest it. An effort to further refine a tag with additional tags to further describe the feature on the other hand, would be most welcome.

I will further quote @Mateusz_Konieczny, who once quite eloquently wrote on similarly contentious forest tagging:

with new tags we have luxury of making definitions. In case of tags used millions of times it is too late to introduce definitions changing how tag is used, we may only describe real usage

9 Likes
11

In general I agree with your classification of the 3 cases.

I also agree with others in this thread that keeping service=alley for Case 2 presents the difficulty of not knowing if a way is really Case 2 or if it hasn’t been retagged to one of the other cases yet, so I would suggest a new service=* value for that as well.

Naming is really difficult.

I primarily map in Canada, where almost all ways currently mapped as service=alley are Case 1. We call them “alley” or “lane” or “laneway”, often interchangeably, sometimes prefixed with “back”. Take for example this blog post from a Vancouverite: “You can, and routinely do, refer to this little road as your “lane” or your “alley,” freely prefixing either usage with the word “back.”” In my usage in Toronto, I would lean towards “laneway”, but would readily understand the other terms and not consider them wrong. (I don’t know what terms are used in Canadian French.)

service=utility for this would be pretty meaningless to me, and service=lane meaning something else would be unfortunate. But, not being local to where Case 2 and Case 3 exist, I can’t really suggest other names that mappers there would recognize.

If we had to, if we can’t come up with better names that describe these unambiguously worldwide, we could probably make do with the suggested names if iD and JOSM prefixes/validators were updated at the same time, with names/descriptions for the three new tags, localized to local needs.

So that e.g. en_CA would have:

  • Case 1: service=utility: “Alley / laneway”
  • Case 2: service=alley_new: “Very narrow city street, cars can fit”
  • Case 3: service=lane: “Narrow city passageway, cars can’t fit, used by motorcycles”

And then other locales like de_DE or vn_VN or for that matter en_VN would have different descriptions to help mappers pick the correct tag even if the tag name itself is meaningless.

2 Likes
12

My usual grumble about those two is that in most cases they aren’t service roads: they are public rights of way, permiting through traffic from public point A to public point B, if with difficulties. They have only been tagged as highway=service because the iD preset was named “Alley” and/or because no other tag combination really fitted.

1 Like
13

If you want “public rights of way, permiting through traffic from public point A to public point B, if with difficulties” to mean it’s not a service road, then the laneway behind my house not a service road either. With these criteria, vast majority of Case 1 uses in Canada falls away - that would certainly make it simpler.

So would you suggest we retag e.g. Way: 8095722 | OpenStreetMap to unclassified, or residential, or something else? Genuinely curious how you would tag the streets and laneways in this area: Brookfield Street, the laneway behind Queen, and the laneway branching off to the north - these are all municipally owned and maintained and there are no legal access restrictions.

image
image827×890 127 KB

1 Like
14

That one looks like the canonical service=alley, as defined in Wiki:

An alley or alleyway is a narrow highway=service road usually located between properties to provide access to back gardens, rear entrances, fire exits, and storage areas. Alleys are normally found in urban areas and often run between the rear sides of buildings such as houses and commercial premises.

…which I’m suggesting leaving well alone. I had in mind the “alleys” as in Rome and many other medieval cities:

AlleyInRome
AlleyInRome1487×817 239 KB

3 Likes
15

Yeah, trying to disambiguate these use cases with
service=utility, service=alley and service=lane just makes it more ambiguous, especially in Canada where “(back) lane(way)” and “alley” are synonymous. I would also shy away from the usage of =lane so that it isn’t confused with lanes=*, turns:lanes=*, etc.

5 Likes
16

A description won’t substitute for a succinct, intuitive name. No matter how much nuance we pack into a description, the name or tag value will practically dictate usage in the long run. Let’s keep trying to come up with a more apt tag value and English name. We may need to ignore regional dialectal differences in favor of (arbitrarily but unsurprisingly) settling for British English, just as we ignore the fact that, in some varieties of American English, “driveway” means any service road and “motorway” means a dirt track through the woods.

That’s a helpful distinction, though I’m not entirely sure that new tagging is the only solution.

Back in 2010, I mapped hundreds of alleys crisscrossing Washington, D.C. As an armchair mapper, I could clearly see the alleys in Yahoo! imagery – and that’s saying something – because the alleys are tidy, well-paved, wide, and predictable, like the rest of the city’s street grid, nothing like the warrens in the old cities of Europe or Southeast Asia.

Several years later, I went to work for a company based in Washington, D.C. At the time, the headquarters was in a garage along an alley wide enough for a standard car, used mostly by garbage trucks and delivery trucks, as well as joggers and bicycle couriers avoiding busy street traffic half a block away. This alley location got a unique address with “REAR” as the unit number, to avoid getting confused with the weightlifting gym facing the front.

A garbage truck turns left from one alley to another at a T-intersection outside the Mapbox garage. Though surrounded by closely packed buildings, both alleys are wide enough to accommodate this truck, maybe even two abreast in a tight squeeze.
A garbage truck turns left from one alley to another at a T-intersection outside the Mapbox garage. Though surrounded by closely packed buildings, both alleys are wide enough to accommodate this truck, maybe even two abreast in a tight squeeze.1920×1350 207 KB

One would think Mapbox, of all companies, would appreciate OSM’s coverage of alleys, but actually it was a thorn in the side of everyone working on navigation software there. Users always got annoyed by OSRM or Valhalla choosing to go down one of these alleys instead of patiently spending an extra few seconds on streets, so it was imperative that the routing profile avoid alleys as much as possible.

The alleys typically connect to streets on either end, allowing through traffic, and you can technically use them as shortcuts to divebomb around traffic. Even so, no one would want to rely on an alley as part of their route, unless they’re headed to or from the Mapbox garage, because it’s too uncomfortable and unpleasant, too much of a hack.

The medieval lanes, side alleys, bylanes, passageways, warrens – whatever they’re called – are more important than stereotypical back alleys. You still wouldn’t want to use it as a shortcut, except as part of an action film chase scene, but it’s much more likely to be the primary access route to your destination. In other words, even if service=alley might be a stretch for this purpose, highway=service can still be a good fit. But I still think “alley” isn’t that bad. Ho Chi Minh City’s alleys (by name) form a maze as intricate as any in a European old city. It’s an “alley” by name, and D.C.-style alleys don’t exist here, so there’s no real need for a distinction.

(Oh look, the street signs helpfully give a width, so you don’t have to take out a measuring tape. :sunglasses:)

A router probably doesn’t need us to distinguish the two kinds of alleys by explicit tagging. Instead of excluding alleys altogether, most routers would penalize them and any twists and turns within them. That’s probably enough to avoid the divebombing while still guiding Grab motorcycles into these residential areas.

3 Likes
17

It would be better to subclass alleys with alley=whatever if there are several subtypes, rather than attempting to change a tag with 1.7M usages.

the reason for the new proposal is that people dispute highway=service is applicable

18

If there are hundreds of thousands of usages for these disputed cases (without seeing the numbers), then it’s applicable because the consensus has clearly expressed itself through tagging.

1 Like
19

What’s expressed though? Most users might have used the “alley” preset, without ever knowing it’s =service + service=alley , let alone deciding on this.
alley= would clarify service=alley , but not tackle the disagreements with =residential . If alley= is to be adopted, another attribute could yet be created for =residential .

1 Like
20

residential=alley?

This maintains compatibility with existing renderers and routers. The preferred rendering should be narrower than =residential without subtag but data consumers that don’t support the new subtag could just treat them as any other residential street.

This would be for streets like this (Google StreetView link) which don’t seem to have much in common with the back lanes of Toronto, other than the fact they’re narrower than modern residential streets.

I don’t think there are hundreds of thousands of examples like these - personally I’ve mostly seen them tagged as service=alley in Italy. In other cities I’ve mostly seen similar streets tagged as residential. So if there is now a bit of momentum to unify the tagging, then I think that’s a good thing.

2 Likes