Highways wiki revisions feedback

We are opening another tagging discussion, but this statement is not right.

A service is not limited to private estate. Here additional subtags matter.

Wiki:

Description
Generally for access to a building, service station, beach, campsite, industrial estate, business park, etc.

An alley is a good example of a more public highway=service. An access road to a remote facility as well.

Regarding the track discussion: shall we add a hint that in case of paved surface the function should be carefully checked?
If needed even with the further note that long stretches of paved surface ard meant, not intermittent surface changes of short sections.

As had been pointed out: a paved surface helps in agriculture to use heavyweight machinery. In an muddy area, the main route to transport tons of rice might be paved.

Maybe we have to look also at canal roads a bit closer. Frequently one side of the canal has a classified road which is used for main traffic, while the other side is much smaller but still paved. Like the example I picked above.
Unclassified could still fit and would justify to change it from track.

It causes so much pain because this issue, like so many other tagging issues, is contentious. There are people in both camps and they have different, sometimes wildly different, ideas about how things should be done. For example, from where does the above-mentioned rule about service roads only being within private estates come?

The Wiki states: “For access roads to, or within an industrial estate, camp site, business park, car park, alleys, etc.” There is no mention of a requirement that it be on private property. I have used highway=service to tag other types of roads in addition to driveways and parking aisles. I have strong feelings that my usage is valid and that it is not forbidden in the Wiki. So, we could have a long conversation about that if we want to take it on. I could argue against that rule but for now, I choose not to.

Maybe some other time LOL

You are correct, and the Thailand wiki needs to be updated to reflect this. We somehow missed this, and I even mentioned it recently to @nitinatsangsit.

Still, as far as understand, highway=service could not apply to a road whose main purpose is access to forestry/agriculture and which leads to no specific place (e.g. temple, attraction…). Do you see it the same way? or do we make an exception when the road is mostly paved?

It would definitely help, and we should do the same for other highway classifications when the surface is unpaved. Too many agricultural tracks have been retagged to residential or unclassified (e.g Grab) and this is a much bigger issue than this paved track topic.

The minor roads table and decision-making tree in the Thailand wiki (which takes precedence over the global wiki definitions) do not currently include any mention of leading access for highway=service.

Lol. You are the only one in this thread that has an issue with this paved track topic and you still haven’t provided any specifics regarding this “pain”.

The only reason topics can become contentious is when guidelines are not good/clear enough, or people are unwilling to compromise or change.

The goal of these wiki revisions is to ensure that regular contributors map with a very similar method/understanding so we can make it a friendly environment for both existing and new mappers.

I picked a very bad example, I did not know you had invented it and did not mean it as an attack on you or your invention. It was just the first tag that came to mind when trying to come up with a good example.

I am sincerely sorry that threads like these causes pain to people, but as you mentioned yourself, we all believe we’re correct in our own ways (and sometimes strongly), so it can sometimes be difficult to accept something we consider an inferior solution. This isn’t meant as a jab on anyone, mostly just an observation.

No problem, Johnny. I didn’t feel attacked. I took your comment as an opportunity to mention the revised tagging for stupas.

Also, the “pain” people are referring to isn’t my pain. Someone else used that term and I replied in the same vein. I started this topic so I could express my dislike of a tagging scenario that allows a track to be paved and possibly to stop that practice. My reasons for objecting have been overruled.

End of topic.

@AlaskaDave sorry, If I continue with the topic. At least some aspects of the mentioned table in the wiki needs further discussions.

I know it is tempting to have a guide-book which exactly tells how to tag what. Unfortunately, due to the way OSM works, this is not possible.
We should not re-define established meanings of tags, but hint towards the specific situation in Thailand and how to apply the tagging here.

I added a hopefully introduction to the table:

Always check the main wiki pages for a detailed description of the tags and some examples on how to use them along with other useful tags to add to them as well. The below table gives some hints on the tagging to cover the specific situation in Thailand.

For the highway=track, I added a note as discussed above:

Especially for paved roads double check the function the road serves: Would you recommend this road to someone travelling from A to B? Then it is probably no track.

I think we all agree that the function of the road matters and not physical attributes like the surface. Still both comes together. The more important a road, usually the better the road.

When wondering about road classification, I usually ask: Would this be the road to take if you want to go from A to B?
Maybe the road I picked by luck above is a nice example to discuss this further. You can see that on one side of the road we have this small road with concrete pavement, while on the other side of the canal we have this wide asphalt road.

The small road is tagged as track: Way: 559237369 | OpenStreetMap
The wider road is unclassified: Way: 526559398 | OpenStreetMap

Unfortunately, no one had yet been on the ground to see the mile-stone which identifies the wider and nicer road as ref=สพ.4056 (Google Maps)

So we have exactly the typical problem. Roads had been added by some remote mappers (not important whether it was Facebook, Grab or a different party) and the classification was guessed.

If you are on the ground, then you would clearly say: everyone who wants to travel along the canal should use the road on the eastern side. That is the “main” road. The other side is only used by farmers to access the fields or by people who have houses there (guessing on farmers again).

This specific problem comes due to the remote mapping. Our wiki table can’t solve it. It requires “on the ground” survey (or recent street-level imagery).
We might now say: Yes, we need a tag to know that a road tagging was “guessed” by some machine or remote mapper. At least for the large-scale Facebook edit we have this. The roads above have the “import=yes” tags on them.

Exploring a bit the area with Google gives us an impression of how it might look on the ground.
In the west-side way along the canal, I already mentioned that it also has some houses along the canal. So the road also serves the purpose to access these houses. Maybe it is still mostly farmers using the road, it is also visitors to these houses.

These houses do not really form a settlement. So tagging the road as residential sounds wrong. It might still be “mainly” agricultural and the access to the houses is then the minor usage. Und having a paved road might lead people to build further houses there.
Or we could see that these roads are more used for “access”. Then it might justify highway=unclassified. This is where Dave’s initial point came in that a track is never paved in Thailand.

If we would tag the tertiary road correctly, then in this specific example we would have no issue with routing, as the travel cost used for calculation would lead to a clear preference of the tertiary only a few meters away.

But situation could be different. I came up with this road:

Imagine, you are travelling southwards on the 2012 and you want to continue north on the 4050. Currently, this paved road is tagged as “track”. This prevents routing for cars over this segment.
But what if we would tag it as “unclassified”, then we save some kilometers including traffic lights, so routing engines might consider this as the “shortest route” and guide you there. I tried routing on OSM data in Thailand before and I ended up being guided through such “shortcuts”. Since then I no longer “just use” OSM for routing but preview routes on aerial/Google, or simply use Google right away.

Check out the Streetview: You do not want to drive your city car this road and want to meet a truck on this narrow one: (Google Maps)

If the ground-survey looks like streetview, I clearly agree to tag this road as track, even having some concrete pavement. It only provides here access to rice fields. Certainly, the other aspects of this roud should be tagged as well, especially the width or maybe lanes=1 to clearly mark this as a minor road.

Trying to summarize it a bit: Function of the road is a good indicator for classification. And it is important to tag other road properties like surface and width to have the data available to make informed decisions when doing routing.

BTW: I did tag roads which only prove access to eg a forest temple as service. I feel this appropriate, but we can certainly discuss this as well. Maybe better then to open a specific thread for individual tagging where we could also collect real-world examples of the tagging.

1 Like

note that highway=road can be used if classification is unclear

Please look at the discussion a few years ago regarding the Facebook activities.
There are no significant highways left unmapped. Problem is how to properly clean up that large-scale Facebook import as we are detecting more and more issues like how to deal with paved tracks or a huge amount of unclassified roads.
Facebook import left us with 715153 ways having the import=yes tag indicating that it was not surveyed on the ground.

To not drift away too far, I created a new topic for the Facebook import validation:

@ stephankn wrote

f the ground-survey looks like streetview, I clearly agree to tag this road as track, even having some concrete pavement. It only provides here access to rice fields. Certainly, the other aspects of this round >>should be tagged as well, especially the width or maybe lanes=1 to clearly mark this as a minor road.

Referring to the way (id:527984298) you supplied as a Google Streetview: I have tagged many similar very narrow paved roads near me with highway=service, service=agricultural, surface=concrete, and lanes=1. These roads are used for purposes other than agriculture, for example, bicycling, fishing, canal maintenance, but to me, this is a sensible tagging scenario. You definitely wouldn’t want to meet a truck on such a road but it’s a useful shortcut that hundreds of motorcycles use daily. And I must candidly admit, I would have trouble tagging this as a track.

Google Streetview

I have to admit I never heard about service=agricultural before. With less than 700 usages world-wide it is certainly not that common.

In which way does this differ from a track?

I appreciate that you are adding the additional tags for width and surface. This allows data consumers to get an better idea about the driveability.

1 Like

I might be one of the first to use that (undocumented) tag. When I was trying to decide how to map these ways a few years ago, there was nothing else that felt suitable. It seemed to fit with my conception of a service road that is being used primarily for agricultural purposes; the service=agricultural tag seemed a logical way to describe the road’s purpose, even though it’s not an “official” tag.

I think it differs from a track because it is fairly heavily used, is used by various types of vehicles, and it’s paved. See, there I go again.

I honestly don’t know why I resist this concept so much. I keep trying to explain it but we’re simply in different camps. Luckily, I am not doing the amount of mapping I used to do so the existence of such things as paved tracks won’t interfere with my well-being too much.

If we are in complete agreement on the usage type, and the only difference is just how we tag it:

highway=track, tracktype=grade1, surface=concrete vs highway=service, service=agricultural, surface=concrete, then I’d rather stay with the currently established standard which is documented in the official wiki, instead of inventing new tags just for Thailand.

3 Likes

This entire conversation is only occurring because there is a category of road that is missing in the whole scheme of things.

The highway=unclassified category is for the public traffic between small villages and hamlets. When it reaches the village/hamlet it then has the option of a highway=residential for public traffic within the village/town to reach the individual homes within that community.

The same option does not exist in the rural areas where the public highway=unclassified then has to be used in both cases. How does the public highway=unclassified relate to the road that serves the individual homes within that rural area? There is no transition from public highway=unclassified to public “rural residential” road (or “minor rural road”) that serves the purpose of getting public traffic to serve these individual homes/farmyards in the rural area. The result is this misuse and misunderstanding of the difference between the public highway=unclassified and the private highway=track.

By introducing a public “minor rural road” (highway=rural) the whole misunderstanding of the use of public unclassified and private track goes away.

Alternately there could be the introduction of a new category between Tertiary and Unclassified that shows the importance of traffic between small villages/hamlets and then unclassified becomes the minor rural road.

2 Likes

I agree that a “quaternary” category and a better name for “unclassified” would solve many of the current issues but there we are, we have to find a solution with what we have available :slight_smile:

I completely agree, the last thing we want is to come up with new undocumented tags. I agree the current tags available and wiki definitions are confusing and it’s very difficult to choose between a service/track/unclassified minor road.

If anyone has a good proposal to make it less subjective to pick between the different minor classifications, please feel free to include it in this thread or a new one.

1 Like

I feel that some of the trouble is also to the fact that a road might well serve as a valid shortcut if you are there with one of the 125cc motor-cycles which are frequently used. Like the road I mentioned (Highways wiki revisions feedback - #26 by stephankn) or the example of Dave (Highways wiki revisions feedback - #30 by AlaskaDave). It might still allowed to use the road with a city car, but no same person would do it.

So what options do we have to indicate that it might be technically allowed to use such a road by car, but it is not advisable.
My idea is to add the relevant physical properties of the roads, like width, lanes and surface. Then routing software has the chance to consider the road or not, based on your routing profile.
If on a motor-cycle or bicycle, then the mentioned roads might be even preferable over wider and higher traffic roads.

Speaking about traffic: Are there any existing tagging schemes to indicate the “frequency” a road is used? Like heavy use/traffic vs. rarely used? Probably based on vehicle class. This could give routing software also the required hints on route selection.

smoothness is the tag that you are looking for.
It’s one of the main tags used by routers (with tracktype and surface) to detect unpaved/rough conditions.

Example: OsmAnd routing code will avoid unpaved roads when smoothness matches very_bad (high clearance only), horrible (4wd only), very_horrible (specialized offroad only) or impassable.

Found this disputed tag: Key:traffic - OpenStreetMap Wiki

1 Like

Smoothness doesn’t fit for the examples given. Both are paved ways with concrete surface. Quite smooth.
Width/lanes could hinted the router in this specific case.

1 Like

Below is a proposal based on global feedback that I believe would solve most issues, let me know there what’s your opinion: