See Etiquette:
- Assume good faith
- Learn to live with the reply-to setting
- Don’t publicly call people out
The “mailing list” Etiquette your refer to also says ”If you’ve made your point already, you don’t need to tell us all again"
You’re a strong supporter of service=alley for narrow residential roads, and I respect your take. Maybe we’ll consider something similar to what’s done in Brazil. But, let’s hear from the Thailand community on this topic. Thanks for making your point loud and clear!
This is only valid within the same thread. It cannot be assumed that readers of this thread have also read all the other threads, such as the one about service=alley. So, this is inevitable as the two topics overlap.
I am still in favor of only using highway=residential for public front access residential roads. By the way, given how widely used service=alley is over the world, I wouldn’t be opposed to using it if we could establish some solid criteria for them. I’ll add some ideas here.
First, service=alley is a sub-tag, thus it is optional. It is not wrong to tag the way just with highway=service; hence, we should only use service=alley for roads that are appropriate to highway=service.
A highway=service is typically not used for a through traffic road. In other words, people rarely use that road unless it is absolutely necessary.
As a result, a service=alley should be used with caution on highly limited roads, such as very narrow roads. We can position it between highway=path and highway=residential based on width. The particular number of width should be determined.
1 Like
Here’s the input from Grab, who leans towards the highway=residential + lanes=1 approach but is willing to adopt a different schema if there’s a community consensus, similar to a few other countries:
1 Like
I personally delved deeper into the OSM usage of service=alley in Northern Thailand, and I couldn’t formulate a concrete proposal.
- If we consider roads where bi-directional traffic is possible only at certain spots (width less than 4 meters), this rule would apply to literally millions of roads.
- Conversely, if we consider roads where bi-directional traffic is strictly impossible (no gaps or presence of walls/fence/buildings/sidewalk), we could find a much lower number.
However, there is no standard road width in Thailand; it can have any measurements. This is open to interpretation, and examining usage samples below reveals that service=alley has been applied indiscriminately for various widths (some are 4/5 meters wide) or even for different uses (private driveways).
I routinely modify motorcycle paths (narrower than 2 meters), and distinguishing them is challenging, especially without a visible car parked in the driveway.
Apart from the reasons mentioned earlier, I personally believe that introducing another highway tag based solely on road width not only complicates matters but also increases the likelihood of further editing conflicts.
1 Like
I have reached out a week ago to regular Thailand community members whether they have a concrete proposal for service=alley taking into these points below but I have still not received any answers.
- Should we make exceptions for narrow residential roads within a certain width (like 3 or 4 meters)?
- How do we ensure that estimating the width doesn’t lead to conflicting opinions?
- Should we base the classification on the presence of “in-between buildings” or walls/sidewalks?
- Does the classification apply to one-way streets, or only those allowing bi-directional traffic?
Historically, most Thailand community members have expressed a preference for labeling narrow roads with highway=residential, and this is currently reflected in the wiki.
To transition to service=alley for narrow residential roads on the Thailand wiki, we would need a clear, non-conflicting proposal for service=alley, followed by a vote with a substantial majority.
Anyone? @stephankn @Mishari @AlaskaDave @Johnny_Carlsen @Mark_B
I think the second criterion might make more sense for Thailand in general, especially in rural areas. Although in urban areas I think local mappers might consider using service=alley for older narrow streets designed with a smaller width than modern local streets in the same area according to current city plans, if available.
To save you time and effort, it would be best to be grounded with some statistics (“millions” might be an exaggeration, but “tens of thousands” seems more likely to me). I suggest taking a random sample of at least 30 (hopefully around 100) residential streets and describing their characteristics in a table (total width, total lanes, traffic lanes, possibility of overtaking traffic - some roads are not bi-directional, but they can still be alleys, some unidirectional ways are quite broad) to estimate how many ways would actually be affected by each criterion. Try to be truly random, for example, generate a random pair of coordinates, then select the nearest residential street (which may or may not be currently mapped as a residential street, so this might involve a bit of extra checking). Then try applying each definition in a JOSM layer without sending the changes back to OSM, and evaluate the results with each criterion to assess the impact and quality of the result (readability, impact on routing, possible other implications, although I haven’t seen any raised in the debate so far). This exercise can probably be done in a few hours.
Hi @julcnx,
Thank you for persevering on this issue. Since cars are not allowed to be more than 2.5 meters wide in Thailand, I would argue that the maximum width of an alley should be no more than 4 meters. I reckon it could be one or two ways as well. Basically two trucks should not be able to exist on the road side by side.
There could be a conflict, but even if it is, it’s not really a big issue. Two eco cars could probably pass each other in an alley.
My understanding of an alley leans more towards roads where a truck can’t pass and a city car might have to drive very slow/careful. Usually he more narrow ones only used by motorbikes/sidecars.
edit: if the road is too narrow for cars, then highway=path is also there. But if it is technically possible, but usually just avoided because of the narrow space, then I lean towards alley.
In the sample photos by Jules, only the first in second row fits in this category. Others are either different serice or residential.
In the case of the typical gated community, the roads are much wider. They are built for the residents to drive there with their cars. And usually also wide enough for trucks to deliver water/gas or collect rubbish.
The example of Usage of highway=living_street + service=alley in residential areas - #10 by julcnx seems to fit here.
For these I favor highway=residential with at least lanes=1 and if possible also with additional tags like width=*.
I wonder how we can come to a good agreement which is also working out in real life. It should be easy enough to be understood also by less experienced mappers.
Can we collect samples (with photos) of the corner cases everybody has in mind? Also if the road faces a specific problem like being suggested by routing as a shortcut.
For routers, we have not discussed about the access tags. permissive/private had been used in this context as well.
1 Like
May I suggest the following simple rule of thumb?
If a street or road cannot be easily expanded (due to the presence of buildings, walls or fences or other significant barriers) to allow two cars to pass each other or overtake one another, then it is alley-like and should be mapped as an alley. Generally, this would apply to streets with a total width (including sidewalks) of 4 meters or less and to rural roads without structures on different sides at a distance of 4 meters or less.
The following cases would not be alleys:
- narrow rural roads with some space on the sides - possibly covered with some vegetation, but not buildings or similar obstacles (like poles, rocks, etc.)
- 2 or 3 lane streets with only 1 lane of traffic and the remaining 1 or 2 lanes for parking (these could be easily turned into wider streets for traffic at any time simply by changing the traffic signage)
- probably rare: 1 lane streets with wide sidewalks which, if removed, would allow increasing the lane count to 2 or higher; if most of the area is for pedestrians, one might argue it is mainly intended for pedestrians, so highway=pedestrian with motor_vehicle=yes might be better
I do not really see why the possibility to expand a road or not hints towards its classification. We should map what is on the ground, not what a road could or could not be turned into in the future.
Can you please point to examples where your rule of thumb is already in use (wiki link, photos of the on-the-ground and similar)
If you already have a lanes=1 mapped, why then not simply stick with residential, which describes the use of the roads in a residential area. Providing access to the main network for the residents.
Because it is more static over time, which is a desirable property of road classification. It also reflects the intended use of the way in local planning. It also more closely matches what the original text of the wiki intended by “old, narrow, medieval ways”: it is definitely not the architectural style that motivated using alleys for those ways, but the fact that they are narrow, with thin maneuvering margin, almost no visibility at corners, and likely to stay that way forever.
There is no classification strictly on the ground. But there is importance and function in context, covering a large area. Highways are difficult to verify,
In Thailand? (I am an observer from Brazil.)
I’m probably the person most responsible for the use of highway=living_street in Vietnam – not because I use this tag at all, but because I really struggled to find an intuitive Vietnamese translation of the term “living street” to use as the preset’s name in iD. The current translation, “Đường Dân sinh”, could easily be confused with the translation for “residential street”, “Đường Nhỏ Dân cư” (small residential road). It’s difficult to come up with translations for legal distinctions that don’t exist in the countries where the language is mainly spoken.
1 Like
This sort of thing can happen even with languages that are linguistically close to English. The word “alley”, for example, is translated to French as “ruelle” meaning “narrow street” (literally “little street”), that’s probably why I found several narrow streets in Paris and Strasbourg mapped as service=alley. Even the dictionary definition of alley in English allows using the word for narrow streets that are not always side or rear access. My point is that it may be too late to enforce the UK/US meaning of alley on the world as local communities did whatever they wanted with it a long time ago, and it doesn’t impact the map much as these are relatively unimportant streets, unlike, say, highway=tertiary and above. So maybe it’s better to be pragmatic and see if there’s any local definition of alley that is actually useful in the local context, without having to strictly adhere to a foreign definition, but also not drifting away from it too much.
1 Like
Oh, sorry, I misread the message I was replying to. Unlike “living street”, “alley” has a straightforward translation into Vietnamese. Depending on the region, ngõ, ngách, or hẻm appears on street signs and in addresses, and “alley” is accepted as the English translation for all three words in an address. However, unlike in Western countries, alleys are much, much more common in urban areas, and there isn’t really a concept of an urban residential street that wouldn’t be called an alley.
The Vietnamese community has a well-established guideline to reserve service=alley for the narrowest alleys, with the rule of thumb being one car or two scooters abreast. But in practice, it’s extremely inconsistent because of armchair mappers from abroad applying their own local expectations. Ironically, every street name sign indicates the width of the right of way in meters, so we could even set a numeric threshold for alleys, but that would require mappers to read the directions. Meanwhile, here in the U.S., I see the reverse: mappers from abroad routinely tag alleys as residential or even tertiary streets because they’re so wide. 
Thank you Fernando and Minh for providing input in the tagging practice in other areas of the world.
This topic started three years ago to clarify the tagging scheme for roads within gated communities (residential alreas). This is typically a larger plot of land, wehere a company build then infrastructure and individual houses. Frequently there is a wall/fence around it and one entry point with a guard and lift-gate.
We had an agreement, which was documented in the wiki. Then three weeks ago, Julien brought up the topic that some mappers stick with a conflicting mapping scheme and started an initiative to review whether our tagging scheme still fits or needs adjustments.
The conflicting point seems to be that some routing engines might send traffic through not suitable roads as a shortcut.
I would still see some examples of where this happens. I believe I posted one such “bad shortcut” example in a different thread a while ago, but don’t find it right now.
Maybe pushing harder on routing engines to take the lanes attroibute into account is a more fruitful approach in fixing the problem.
1 Like
I stand by my earlier comments in this thread. service=alley implies a narrow way that is sometimes passable with a normal vehicle but doesn’t provide access to the front doors of any residences. If it’s so narrow that a small car cannot fit, then it should be tagged as path with motorcar = no, motorcycle=yes. However, if two cars can pass easily, I would be reluctant to use service=alley. There are very few ways that meet my strict criteria for service=alley in Chiang Mai.
Due to the lack of any legal definition, highway=living_street should probably never be used in Thailand and I have never used it to my knowledge. highway=residential with access tags (e.g., access=destination and ownersip=private) might better serve the purpose along with enclosing the area (if it is a neighborhood), in question and tagging it as a gated_community=yes. Routers might have trouble with this but IMO the routing algorithm needs to change, not our mapping criteria.
2 Likes
I compared different maps and how they route narrow roads.
Soi Chana Songkhram was mentionned What is the recommended tagging approach for routing narrow residential roads? - #11 by ftrebien
This is a max. 2.50 metres wide road tagged as highway=service. The oneway tag is missing in OSM. Way: ซอยชนะสงคราม (550732347) | OpenStreetMap
OpenStreetMap car routing
.
Both HERE maps and Google maps avoid this road for car navigation although the Google street car has driven through.
.
motorcar=destination could be used for a narrow residential road that routers mistakenly use for transit/shortcut. This is tagging for the router I believe.
residential road or alley?
It does look strange on the map when a 2.5 metres wide road is rendered the same as a regular 5 metres wide road. But that is what HERE and Google also show. I would have liked this solution: highway=residential + narrow=yes. The wiki says that narrow=yes will render waterways smaller. It does nothing for highways.
I usually tag narrow residential roads this way:
highway=path for a road too narrow for a city car
highway=service + service=alley for a road between approx. 2 and 3 metres
highway=residential + lanes-tag for roads of more than 3 metres.
highway=living_street
I don’t use it. I use highway=residential instead
2 Likes
Thanks for your research, Mark_B!
I’m curious why Soi Chana Songkhram was used as an example. Historically, it’s never been labeled as service=alley, and on Google Street View, it’s clearly marked as one-way on the north side.
Anyway, today I added extra tags: width=2.5 + lanes=1 + narrow=yes without changing the highway=service classification. I’ll report back in a few days once the routing data has been processed.
In the meantime, please take a look at another example in Bangkok:
https://www.openstreetmap.org/way/707081726
It’s tagged as a narrow bidirectional residential road with highway=residential + lanes=1 + width=2.5 + oneway=no.
Though the width and choice of highway tag are debatable (motorcycle path ?), the default OSM Router completely avoids it in both directions:
https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=13.71773%2C100.52527%3B13.71850%2C100.52358#map=18/13.71891/100.52461
Here’s a proper narrow residential road in Chiang Mai tagged as highway=residential + lanes=1:
https://www.openstreetmap.org/way/47484437
Routing from beginning to end of this Soi shows the router avoids it completely in both directions:
https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=18.78752%2C98.98804%3B18.78712%2C98.99031#map=19/18.78766/98.9891
Another example is here: https://www.openstreetmap.org/way/148818706
Again, routing from beginning to end of this Soi shows the router avoids it completely in both directions:
https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=18.78279%2C98.98280%3B18.78254%2C98.98541#map=18/18.78228/98.98636
Conclusion: These results indicate to me that the argument of tagging for the router is unfounded since the default OSM router already supports additional tags like lanes, width, and even narrow:
https://wiki.openstreetmap.org/wiki/Routing/Narrow_Roads
Sure, other routers may need better support, but we can all contribute to improving this together (see below).
Absolutely right, and you know what? Renderers and routers aren’t set in stone; they can be improved over time, whether through tags like narrow or lanes=1, or other means.
But software won’t improve without people submitting feedback and improvement requests.
I personally believe that as regular OSM contributors, community members, and end-users, we bear the responsibility of enhancing the OSM ecosystem, making it a better environment for everyone, including new mappers.
The easy way out is to tag for the renderer/router and repurpose tags meant for something else.
However, as you can see, this often leads to long-term contentious issues, edit wars, and a lot of wasted efforts that could have been directed towards improving the softwares instead.
1 Like