Worldwide routable Garmin maps: Missing/incorrect feature requests

I get this message from mkgmap using the OFM full style:

Geofabrik extract Hamburg. No message with mkgmap default style.
Indeed routing is different. Bug, feature? Or do I miss something?

I think this restriction implies for cars, part of those ways are forbidden for bicycles, and thus a non routable line is used (for example this via way: https://www.openstreetmap.org/way/503043835). Mkgmap sees this and complains that something is missing. I think you can simply ignore this error.

This is an error in mkgmap. I can reproduce it and should be able to fix it.

Thanks Gerd!

OK, the error is fixed with r4141. No need to compile the map again, the message was printed for the route restriction that was already detected as invalid before but not marked as such.

Gerd

Thank you both!

with newest mkgmap 4160 and 4164 I get the following:

I didn´t follow the latest development deeply - is this now a bug in the style or in mkgmap?

Request : Rendering of areas marked highway=services

In Thailand, at least, we have many of the larger fuel stations marked with a boundary tagged highway=services. Some include the area=yes tag, while many do not. A typical example can be seen here ; http://www.openstreetmap.org/#map=19/16.42704/102.87641

Is it possible to have mkgmap pick up these areas and render in suitable colour, either sharing the shading of say, industrial, or even allocating a new hex code ?

We do have a separate issue in the above example where the Garmin routing engine does not see the service area as routable, and in this case, to add the Caltex POI to your route, takes you in and out of the same service road. In time, we will solve this by adding a link across the two roads, and if on a dual carriageway, including a one_way tag.

It would be nice if these areas can be routable (as in a similar case to an area drawn as a Plaza) but appreciate this may not be feasible - true, or not ?

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.