I think it depends on the OSM highway tags. It is not a highway=track (normal dirt roads) but a tertiary, those are maybe too wide for the dashed lines?
You can change that by editing the typ file. I’m not sure why you don’t see that label ‘unpaved’
I have found out that the ref tag is the cause, without ref or name tag, the label unpaved is rendered.
I dont know how to solve this, I can’t remove the ref or name tag unfortunately.
Another one: paved tracks are rendered as unpaved roads. I assume the routing engines treat them as unpaved. I realise that in Europe a lot of these are closed to motor vehicles and whence routing thru them is probably undesirable. In Thailand there is a continuum from unpaved tracks to paved tracks to small roads, all usable by any vehicle that physically fits. It is desirable to get routed thru anything paved.
Depends what someone calls paved and what unpaved. That really makes a difference in what country you are. Guess the situation in Thailand is very different than Europe. For my OFM I consider tracks with grade1 or surface=asphalt as paved (same rendering as paved unclassified). Is that what you have in mind?
If my interpretation is correct, it says that all those types of highway are considered as unpaved, unless there is a surface, tracktype, smoothness AND sac_scale parameter! This rule makes no sense at all so must be corrected. The mkgmap default rule is the same so I will discuss this on the mkgmap-dev list first.
I dont understand it Gerd. What does “&” mean then? To me it says make highway=track unpaved if surface AND tracktype AND smoothness AND sac_scale are not empty. Otherwise I cant explain why surface=paved is set unpaved by mkgmap?
I also understand the rule like that.
It should not set mkgmap:unpaved=1 for a way with highway=track and surface=paved
I did not yet try it. If it does I’d say something is wrong in mkgmap.
Now I’ve tested it, and it worked ok. Even with avoidance. The only thing that is not correct is the generic new typ file, it still says unpaved because that is the label if there is no streetname. I can try to correct it by adding a second label.
But still, the syntax is a bit strange: & surface!=* & tracktype!=* & smoothness!=* & sac_scale!=*
Unpaved will not be applied if one of those values is not empty, and I read it as ALL of above values must be not empty.
And then it is still not correct. Say someone tagged the track with surface=soil (1014 values in OSM, but not specified as unpaved by mkgmap). It is better specify a rule like
My fault, yes you are right, if all those parameters don’t exists its unpaved. The preceding rule has to catch all unpaved and if surface=something else mkgmap assumes it is paved. I only need to add label=paved to this rule, but I better prefer a rule like surface=paved etc {addlabel ‘paved’} rather then “if those parameters are not empty” then assume its paved and add a label paved to it
I have decided to change only the label in the typ file. Adding a label ‘paved’ will show up as streetname if there is no name. I cannot make it invisible unless I use or add another line type, but since routable line types are all taken and I don’t want a second line on top of another it’s better to leave it behind.
No routing will not be avoided anymore, appearance will be the same, I don’t think it must be rendered the same as unclassified roads otherwise why dont people tag it like that?
Actually, I am having a hard time sometimes deciding whether a particular road in Thailand is a paved track, residential or unclassified. In the end, all I can do is look at the aerial images to see whether there are a few houses on the road and whether it connects villages or just heads into the rice paddies. As I said, it is a continuum. If in doubt it is residential.
I have an old Edge 705 GPS unit. Is it possible to have a TYP option where the borders of the road sections are not drawn? On a 705 this leads to the “spaghetti problem” as seen on http://www.cferrero.net/maps/screenshots_index.html. Thanks a lot in advance.