Worldwide routable Garmin maps: Missing/incorrect feature requests

In the default style the rule is preceded by this one:

highway=*
& (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 ~ '.*(bad|horrible|impassable)' |
   sac_scale ~ '.*(mountain|alpine)_hiking' |
   sport=via_ferrata)
{ add mkgmap:unpaved=1 } 

So I think the rule is not that wrong.

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

highway=track & surface! ~ '.*(paved|asphalt|sett|concrete|paving_stones|metal|wood)' { add mkgmap:unpaved=1 } 

And what about cobblestone? Paved or unpaved?

I’d rather add the surface=soil part to the preceding rule.

Agree, we cannot catch all types that people have entered.

Actually condition like surface!=* means opposite: highway is unpaved if surface IS EMPTY and tracktype IS EMPTY and …

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.

So, paved tracks will now have a mouse-over label “paved”, but continue to appear as unpaved roads, incl. routing avoidance?

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?

Ok, all good. Thanks for all your good work.

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.

Hi, firstly, thanks for your work.

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.

Hi Zeb,
You can edit the typ file with an editor like typviewer. If you use a bicycle map try my openfietsmap, it is designed to prevent those issues as much as possible.

I already use CFerrero TYP files with my own mkgmap scripts. But it would be great to have a similar one on http://garmin.openstreetmap.nl/ if possible?

Do you mean you already have such typ file and want to give it to the community? You can try to mail Lambertus if he is willing implement it in his compilation chain.

Well, it is based on the work from CFerrero originally, which I modified. CFerrero has not updated his site for years, and removing contour from road lines does probably fall outside copyright, so it should be ok to share. I am happy to provide the files to Lambertus. I will contact him.

I doubt if Charlie will have any objections that you use his style, but it will do no harm if you ask his permission.
Whether Lambertus will implement the typ file or not, I’m happy to host it on github, https://github.com/ligfietser/mkgmap-style-sheets/tree/master/typ as long as you are willing to update this file if it gets out of sync with the latest mkgmap developments?

In Openfietsmap Light maps, type code 0x0600 is assigned to landuse=industrial and landuse=residential areas that have a name attribute. This makes these objets appear in search for cities results. I understand that large named residential or industrial areas can have the same importance than a suburb or village for a cyclist looking for a destination but in many cases small industrial sites like single factories and small residential areas like student hostels, nursing homes and the like are polluting the search result in a way that cities and villages appear on the lower pages of the list or not at all even if they are just some kilometers away.

Therefore, I propose to assign POI type 0x0600 only to areas with a significant size, e.g. one square km.

I dont agree, nursing homes and the like could get a poi instead of a name on the residential area so it should be corrected in OSM in the first place.