After recent talks on Track, etc. it seems the Surface tag is really important…

Just did a search on JOSM of a Highways in an area close to CR for Surface=Unset and there’s loads of ways with no Surface tag - Major roads included. Don’t know best way to handle this, but it is an important tag re. routing, safety, etc - so should be completed.

Bigger roads surface can be ascertained from looking at sat’ pics - and can maybe be tagged as a group using JOSM (?). Any smaller roads off in the country that can’t be judged clearly from sat’ should be tagged as unpaved, IMO.

Better don’t do that: The type of surface is easily mistaken. Concrete may look like dry soil. And a dirt shoulder of a paved road may lead to thinking of an unpaved road.
Don’t worry to much about that tag: most roads of tertiary or higher type are paved (mostly asphalt, some concrete). For asphalt on such roads, I normally do not place a surface tag on that way when mapping in asia, only for concrete or unpaved roads. With minor roads (unclassified, service), I normally add that tag if I know the surface from a survey.

I don’t think we should make such assumptions. If something can’t be seen on a sat image we should not assume something. Better leave it untagged. So it can be found by looking for untagged roads and surveyed on the ground.

It is often possible to see road markings on the sat images to assume a paved road. The other way round is misleading. Is it a dirt road or just a dirty road? Is the road currently being constructed/renewed when the sat image was tagen?
It is also unlikely that a paved road is downgraded into a dirt road. The other way round is much more likely. Depending on the location the sat images are years old. So situation on the ground might be different than on the sat images.

For higher grade roads it might be a safe assumption or possible even a requirement to have them paved. motorway, trunk, primary. These should be paved in Thailand. Maybe even secondary. We might assume paved as a default but tag if they are special, for example unpaved.

Tertiary roads we know from your example region (the 4044) can be unpaved.
So for these lower category roads it makes perfect sense to add a tagging of the surface.

I agree that for the sake of safety of the drivers having the surface tagged in Thailand is maybe more important than in the developed countries in Europe where you have to search hard for unpaved roads as part of the road network (not counting agriculture/service and such)


Seems you both disagree with each other about surface assumptions on more major roads…

Yes, for tertiary and up I guess you can presume it’s paved - but then depends why it’s been tagged as tertiary - if it was just down to function then surface is still a guess. These are more major roads so lots more people travel them - inc’ armchair mappers. So, if mappers at least tag those they know are surfaced through experience - that would be a start. Are there accessible surveys detailing road surface in Thailand? (In TH?)

No, better to not make assumptions - and in theory, I agree with leaving tags off as an easy marker for surveyors… But this is OSM in Thailand - how many field surveyors? The reason I’m saying surface is so important is because people are suggesting that function is most important - and that a bad surface isn’t - and that Surface can just be used as a routing option and for rendering… Well, it can’t if it’s not there.

But then that would be tagging for renderering/ routing - which is not OK… I didn’t think about it properly and was wrong to suggest that - the Surface tag should only be completed on any highway after a survey/surveying reports. (Though I would guess there are plenty of highways on Thailand OSM that mappers have travelled on that have not been Surface tagged.)

However, it is the routing script or renderer script that can make assumptions - eg. if it’s a more major road such as tertiary or up with Surface unset then it might be presumed as Paved, if it is Unclassified or down with Surface unset then it might be presumed to be Unpaved. I think that would help user safety best as a Tertiary up is more likely to be paved or in fair condition even if unpaved, whereas an Unclassified has a good chance of being unpaved and in a bad condition. (Note, there are plenty of minor roads around that have once been surfaced but poorly and then not maintained - so these once paved ways are basically unpaved and can now even require an offroad vehicle.)

Note, hopefully Paths and Tracks won’t be used by routing apps at all - though some do and some don’t as of now. Paths and Tracks should definitely be assumed to be unsurfaced in Thailand but, again, best not add a Surface tag unless actually surveyed. (I can say for sure, all the Tracks and Paths I’ve mapped are not surfaced - for Unclassified, some are and some aren’t.) Renderer scripts can tailor how they draw according to desired map type output.

No reason then to have the Surface tag being guessed at and falsely recorded. Leave it for surveying to tag surface and have rout/render scripts do any assumption making with some flexibility… Though I’m not at all optimistic re. routing scripts as they will likely run on assumptions based from developed road networks where unpaved is rare and way surveying/tagging is far more accurate/reliable.

Just for informational purposes I add the comment that the default styles distributed with mkgmap set surface=unpaved for a variety of surfaces, including anything with a tracktype grade of greater than grade2 (that is, grade2 through grade6) and smoothness values of “bad” or “horrible” or “impassable”. I changed mine by removing “bad” from the test - I’ve seen too many paved roads that were marked as having a “bad” surface appear as unpaved roads on my Garmin yet were perfectly passable. These changes were too strict for my liking so I changed them. @Chris, you may want to take a look at those rules in your lines style file

In addition, and more to the point of this conversation, many roads in Udon Thani that appear unpaved in the Bing imagery are actually paved roads covered with the red dirt common in that area. This I know from personal experience.

So, I agree, we don’t want to assume too much when tagging these highways.

Yeh - they should have it as ‘very_bad’ as ‘bad’ is still defined as OK for normal cars:

‘very_bad’ and worse = not OK for a normal car.

I’ve changed it in lines file already… Not that Tracktype and Smoothness are much good to rely on as so little used here…

TBH, without wanting to put down peoples efforts, I’m seeing a fair bit of sketchy coding and mismatch in the mkgmap default style and TYP.

Can you be more specific, re: “TBH, without wanting to put down peoples efforts, I’m seeing a fair bit of sketchy coding and mismatch in the mkgmap default style and TYP.”

I think those styles and the TYP file are kept as perfectly general as possible because they must work for a wide variety of Garmin units, old and new. I was annoyed that radio towers are not rendered by the generic_new styles. Later I learned that in Europe, where almost every radio and cell-phone tower has been mapped, there were so many of them that they cluttered the map and obscured more important stuff, like roads. I decided to render them on my maps because over-mapping is not an issue over here, haha.

I’m wondering if perhaps what you’re concerned about is something done purposely, or with a Euro-centric bias?

Eg. ref codes used in styles files not matching those in the TYP. The flag unpaved section has code to point at different lines in the TYP if a way is unpaved - but these don’t work without some editing - like removing ‘continue with_actions’… Not that I’m experienced with this script and there’s maybe a reason behind this I’m missing… I’m no coder - I’m not checking through proper - I’m just trying to mod as few edits as poss to get something that works. I don’t even use a Garmin - don’t like 'em!

I’m going to use something like this in the line file - so I can tag as I think suits best for Garmin routing (hopefully) and show unpaved smaller roads differently. Tracks, and paths, etc will show same as, by inference, these are unpaved:

Flag unpaved roads.

& (surface=cobblestone | surface=compacted | surface=dirt |
surface=earth | surface=grass | surface=grass_paver |
surface=gravel | surface=grit | surface=ground | surface=mud |
surface=pebblestone | surface=sand | surface=unpaved |
mtb:scale=* |
tracktype ~ ‘grade[2-6]’ |
smoothness ~ ‘.(very_bad|horrible|impassable)’ |
sac_scale ~ '.
(mountain|alpine)_hiking’ |
{ add mkgmap:unpaved=1 }
(highway=bridleway | highway=path | highway=track | highway=unsurfaced | highway=unclassified | highway=road | highway=footway | highway=cycleway | highway=service)
& surface!=*
{ add mkgmap:unpaved=1 }

highway ~ ‘.(trunk|primary|secondary|tertiary|unclassified|residential|road).’ & mkgmap:unpaved=1 [0x0f road_class=0 road_speed=1 resolution 21]
highway ~ ‘.(byway|living_street|service).’ & mkgmap:unpaved=1 [0x0f road_class=0 road_speed=1 resolution 22]

I’m working off ‘generic new’ from here: The latest v. mkgmap default style and typ could be different.

I am going to have to find people with a Garmin to do some testing, I guess. Not that routing is really important for intended use - so long as it displays ok.


I think Nightrider has done some pretty fancy reworking:

Looks like he’s done a good job - only thing is his zoom/resolution for small ways doesn’t really suit those focused on dirt riding and he doesn’t show path and footpath differently (neither does mkgmap default code). I tried to pinch his style to edit but he’s done lots of work so not keen to hand over - which is fair enough. I think it might be that modded that I’d have a job figuring it anyway. Note, I only have QMapShack and Basecamp to check stuff in of course. Not much idea how things work on an actual Garmin.

Regarding data sources, official road surface data are available for national, rural and (registered) local highways. Thai government works aren’t freely licensed, however, so they’re probably only good for fact-checking on a case-by-case basis. More than that might constitute a violation of database rights.

A lot of opinion above to digest … and I was going to finally disagree with Chris in that surface=unpaved should be added indiscriminately and automatically. My view is that if the surface has not been surveyed do not enter the tag, UNLESS it is clearly apparent from the aerials (ie presence of white lines can only mean asphalt).

Finally, and I hope it prompts a new thread … Chris, I do think routing is important and one problem I see so frequently over here, is the default “generic new” style which from my poor understanding, calculates the roadspeed of a track the same as an unpaved road (15mph, am I right?). This gives some horrendously long routes when in rural areas. Perhaps time for a global review of the difference in roadspeeds for track/unpaved road/potholed sections (notwithstanding unpaved tertiary, and unpaved minor).

Chris, I think you now accept adding surface=unpaved to everything un-surveyed is not a good idea ? Right ?

Yeh, if you look at post 4 you can see I reconsidered tagging Surface…

Re. routing - I was saying that I don’t think Path or Track should be routable - because I was thinking of apps that use OSM directly - mainstream user apps that are typically used by road drivers. That’s because only some routing apps on Smartphones, devices actually let you opt in or out of unpaved ways (eg, Mapme.) - but I thought they might automatically not include Path and Track… This is hard to guess at though, and when I had a quick check it looked like Mapme (quite popular I believe) even lets you route tracks! So, not exactly a common theme amongst routing apps - hard to plan for - and so best not tag for router (or for renderer) - which then at least gives them fair chance to do a proper job depending on responsible (with regard for safety) scripting.

But, you’re coming from a different perspective - and are converting for use on Garmin anyway. In that case, it’s far easier (relatively speaking) to mod the conversion (mkgmap, etc) to produce bespoke Garmin maps to suit - compared to using routing in GPS nav apps (such as Mapme) where you only have built in routing options available. (The issue you raise is really specific to these conversion programs rather than an OSM one…) After a little play with a Garmin, I can see why you use routing more as you simply can’t zoom paths and tracks out far enough to get an overview you can plan a route off - at least not on the actual Garmin. so, I guess you put more reliance on planning in advance, load to device then follow along a small zoomed in area in order to nav… (This is why I don’t get on with Garmin’s. And I route in my head just using the map for reminders.) So, I can see why routing is important on a Garmin - and also am not worried about routing even Path and Track, etc on one really as custom maps can be made to suit users req’s - the default Garmin (non OSM) map hopefully routing to suit typical car drivers.

I’ve suggested to Nightrider that he does a few tweaks (inc making track and path easier to view when zoomed out further) to make a map more suited to dirt riders. I don’t know if he’s keen on this for sure yet but will leave a bit more time to see if he will. If not, then I am playing with a map and might make that available. (I’d rather he does it though, he’s more exp’ with it all then me and already hosting download files.) As for your speed issue, I haven’t looked into it yet but dif’ way types have dif’ default speeds - which can be customised I guess. (And, as you aren’t exactly slow, you maybe need an extra customised map, Russ. Compare your speed on such to someone struggling in a standard car.) See page 26 here for more info: So, even if Nightrider does make an ‘offroad’ map, I’m not sure if you’ll end up with one with speeds that suit u. But, I’ll see what I can do :wink:

@Russ, AFAIK roadspeed for mkgmap and Garmin maps derived from it are set either by reading the maxspeed tag which, as you well know, is hardly ever used in Thailand, or if that isn’t present will be set by rules within the styles files. The default speed for tracks is set for roadspeed=1 (15 mph) while paths are set for roadspeed=0 (3 mph), which is approximately equivalent to a brisk walking speed.

As for the question of tagging surfaces, I think it’s best to leave them unset. When a mapper sees a way in person, then he can tag the surface and add a source tag to indicate that the tag is based on observation rather than on Bing or Mapbox. Leaving them unset simply means he or she doesn’t know what the surface is, which is precisely the point. In the case of good aerial imagery where one can see the dividing line on asphalt, I tag it paved, and with 2 lanes.

Dave - agree with you on the subject of tagging.

Can you confirm the default speed for an unpaved minor (unclassified road) is also 15mph ? And if so, should this not be a bit higher ?

I’m also interested to find out how the routing algorithms work specifically for the OSM data we convert to use on the Garmin … is is simply built into the Garmin units, and if so, what tags get used. I note there are tags available for average speed etc, which is probably more apt for routing than max speed, but are they used by the routing engines ?

Naturally I would be happy to tag the longer trails with average speed based on what is actually achievable, but then how do you compensate for wet/dry, motorcycle/car, fast/slow rider variations ?

The technicality gets boggling at times … and I need to make sue Im never in danger of losing the very reason I contributed to OSM … and thats so as I dont get lost in the jungle !! :slight_smile:


The defined roadspeed levels are tricky, as your question just now pointed out to me. I can say this, the default roadspeed for an unclassified paved highway is 35 mph (class 3). If any highway (trunk, primary, … track) is set to surface=unpaved its roadspeed is defined as class 1 and its roadspeed to 15 mph. Surface “unpaved” includes all variants; dirt, gravel, compacted, etc. Also, note that style rules can manipulate the roadspeed setting in many ways, some of which are not at all clear to me. As I said before though, I believe that in the absence of a maxspeed tag, those defaults would apply.

As for how all that affects routing, I can’t really say. I’ve been meaning to ask for more details from the mkgmap development team but just haven’t got around to it yet. I would assume routing would depend strongly on the roadspeed variable, along with the number of traffic_signals, etc., when computing a route but I doubt average speed does because that term doesn’t appear anywhere in the mkgmap literature. I’m assuming too that it would be impossible for those calculations to take local or weather conditions into account. The maxpeed for a given road is also generally not weather dependent; one must use his own judgement about that.

The Garmin units have software and firmware that nobody completely understands unless they happen to write code for Garmin. It is essentially a “black box” that certain smart folks have learned to trick into using non-Garmin made maps. The inner operations are still mysterious, even to them. They are still learning new tricks.

What we really need is an open source GPS/OS that runs on Garmin hardware. Now that would be something cool!


PS: The other thing that would really help here in LOS is if we could agree on maxspeeds for the various highways. Those could then be either tagged explicitly on OSM or be set by some style rules that would apply only to Thailand. There’s a way to achieve the latter if you’re doing your own maps but in addition to that I think we should pay closer attention to speed limits when we’re out and about and then tag 'em as we see 'em. That said, remember this is Thailand and you all know what that means.

Garmin uses 8 speed categories and 5 road types. The style used by mkgmap defines how OSM tags get translated into those speed and road classes.
Since I use my own style, I cannot tell for sure how things are currently implemented. The default style of somewhen last year mainly built on the maxspeed tag for the speed, and on the highway tag for the road class, with default values depending on highway type and paved/unpaved. The surface and tracktype tags were used for determining if the road is paved or not.
There is no discrimination between driver habits at this level. But if you use your device with a specific map for some time, the device might “learn” how fast you drive on which speed category (perhaps also in combination with road class).
The routing algorithm for shortest distance typically does what you expect, but the algorithm for shortest time often does not. It prefers roads with a high road class (typically motorways and primaries) and may take more time than a route on roads of lower categories. I think the background for this behavior is that the distance of road segments can be stored in the map, while the travel time can not; the time must be calculated from the distance with the speed values learned during your use.