Worldwide routable Garmin maps: Missing/incorrect feature requests

Thats a bug, I think it is just solved in r-4165

I’m not a developer of mkgmap ( better ask this on the mailing list) but I think it is the same with highway=pedestrian, it is needed to add area= yes to mark this as area so the renderer can see it is an area and it is not feasable to make the whole area routable, so you always have to draw extra ways across them.

BTW
The generic new style renders these type of highway areas:
highway=* & area=yes [0x05 resolution 22]
area:highway=* [0x0e resolution 24]

I just installed OSM maps for the first time onto one of my Garmin units, an old GPSMAP 76S, and I was wondering, how would you handle points with the tag “natural=cape”? I don’t seem to see any such points appearing on the map on my Garmin unit.

Hi All

I have just installed the new OSM Generic Routable New GBR_03-07-2018. Everything seems to work fine, however the background has changed from the normal yellow to white. Also when night-time mode kicks in the screen does not go black but more a mix of black/white. Is there something I’m doing wrong during installation or a file that I am missing. This is on a Garmin Zumo 550. Cheers. Rob

@DENelson83 natural=cape is not in the list of rendered features, it can be added though
@RobB86 the new style always has this white background, maybe you are used to the generic routable?

Hi @ligfietser,

I just cloned the git repo and it’s 710 MB. Is it possible to clean this out? Or should I have used a different way to download it?

Thanks,
Peter.

Hi Peter,
It is caused by address data (resources folder), since it is not updated I will remove it, thanks for reminding me.

Great, thanks!

OK, so here is a challenge … I notice in Thailand, and presumably the rest of the world, when a Petrol Station/Service area closed way, is ringed with the highway=services tag (note, in the plural), it seems to create an “invisible area” for routing purposes.
If you try to create a route to any waypoint within this area, the Garmin can not do it on Mapsource.
And if you are in the field, then my Zumo 550 repeatedly states its “Unable to calculate route” until I walk out of the services area, then its fine.
I also see that the Services area, instead of displaying as a shaded area like most other areas, it is displayed as a closed service highway, both on Mapsource and the Zumo Unit.
I guess the answer lies somewhere in changing the MKGMAP program, but that’s beyond my abilities.
Can anyone help ? :confused:

Hi Russ,

As a first step may I suggest you try the same with Lambertus’ default map, i.e. not the new style. It is my understanding that this type of map pretty much represents a default mkgmap output. If the problem occurs only in the new style, then it is up to us here to figure it out. But if it occurs in both, then you need to take that up with the mkgmap mailing list.

Checking the PTT nearby I find that the services area has been converted into alleyway, so it is routable, BUT there are no connections to the driveway. That’s why routing fails. (New style, I don’t have the old one here.)

I don’t know whether mkgmap can create nodes at intersections. That would be a preferable solution. Otherwise, we would have to “map for the renderer”, i.e. manually connect all the services, which is frowned upon.

Regards,
Peter.

Highway=services is only meant for polygons, not for routable ways: https://wiki.openstreetmap.org/wiki/Tag:highway%3Dservices
If you want to route, use highway=service

Then our mkgmap config needs fixing, because it transforms the service station driveway into road type 0x10000, then transforms the services polygon into an alleyway. I think it’s that alleyway that is the problem, because it is not connected to anything and pois are located along it.

Peter, can you point me exactly to the line where this happens? I cant’find any services in the line style.
There is only a mob up rule, maybe this should exclude highway=services?

I’m not sure why you are looking in the line file, as we are dealing with a polygon (that gets converted into a line). I found this on line 68 in polygons:

landuse=retail | highway=services [0x08 resolution 22-20]

However, I have no idea what converts it from 0x08 (shopping centre poly) to 0x07 (alley). I could never quite get my head around mkgmap’s logic and syntax.

Polygons are never converted into routable lines. If you want to get something routable it must be specified in the lines style.
The reason why highway=services is being converted is because of the mob up rule.

# Mop up any unrecognised highway types
highway=* & highway!=proposed & area!=yes & highway!=pedestrian [0x07 road_class=0 road_speed=0 resolution 23] 

It is easy to ignore highway=services, just include highway!=services into the rule above.

Thanks for looking at this. Will the MKGMAP team now pick this up and action ?
And will that simple fix render the highway=services as a polygon, maybe even with a new Garmin hex code if there are any suitable ones left ? :slight_smile:

I can fix it for the generic routable new style maps but for the default mkgmap rules you have to discuss this on the mkgmap-dev mailing list.

In the past, it was suggested to add area=yes for highway=services. This was changed in 2017:
https://wiki.openstreetmap.org/w/index.php?title=Tag%3Ahighway%3Dservices&type=revision&diff=1495988&oldid=1414117
So, yes, I think we should add a rule in mkgmap to handle this.

Yes, they are working on this http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q4/029261.html
Also a default typ file is being developed, so maybe Lambertus “new style” and old mapnik typ file can be replaced sooner or later.

On another issue, under the thread title of “missing requests”, would the addition of a Traffic Light POI (& icon) to the styles be a difficult thing to add ?
It would make life a bit easier, when plotting on the go, to know which junctions have had the lights added, and which still need doing.
Russ.