Worldwide routable Garmin maps: Missing/incorrect feature requests

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.

It would be not difficult but it will create a lot of pois which will clutter the map and makes it unreadable on a small gps screen. Android maps like osmand render them but those maps have a much larger screen resolution so you can display more details.

OK noted. As an interim measure, I used Overpass to pull out the nodes from the Thai map, then created a POI file along with a small icon. It actually looks OK on the Zumo 400/550 and will work fine for me.
Anyway, appreciate the reply.
Rgds, Russ.

I realise this thread may be less relevant with the recent availability issues at garmin.osm.nl, but is it still worth submitting issues for the styles here? I have spotted a couple of things that don’t seem to be right.

A related question would be whether the garmin.osm.nl site automatically consumes these styles when they change, or if Lambertus needs to be involved?

My third question is perhaps a little tangential: I’ve tried building maps myself using the styles discussed here, but I haven’t been able to exactly replicate what I get from the garmin.osm.nl site: it’s probably just a missing option of some kind, or some kind of process issue. Are the scripts used by that site to actually generate maps available for inspection somewhere?

  1. yes please go ahead and drop them here
  2. yes, the latest style from github will be processed, no need to contact him
  3. the generic maps will use the default mkgmap style, the generic new styles you can find here: https://github.com/ligfietser/mkgmap-style-sheets/tree/master/styles/generic%20new

I should start by saying I’m fairly new to all of this and the learning cliff is pretty extreme but I think I’m starting to get my head round things. I’ve been using the garmin.osm.nl “generic new” maps as one of my map sets since I replaced my original GPS with a newer one after the GPS week roll-over.

I’ve been doing a bit of OSM editing in my area, but some things aren’t – or aren’t entirely – OSM data errors. The first thing I’ve dug deep enough that it looks like a style issue is that an area round where I live appears in the garmin.osm maps as “Nature Reserve”, e.g., at N55.93251° W3.17980°. It’s not a nature reserve.

This appears to be the rendering of this feature, which is a designated local cultural conservation area with restrictions on building types.

I think I have two problems here. The first is that it’s a boundary=protected_area (correct) but that the original editor has set its subtype to protection_class=22 to indicate the kind of protected area. I think I’m right in saying that should actually be protect_class=22

It would be interesting to know if anyone agrees that’s mistagged; obviously I can go in and fix it if so. It actually seems to be a common error in this city, with 25 occurrences in the .osm file, probably all by the same mapper.

However, I think that the current style would still render this area incorrectly because the polygons file says:


leisure=nature_reserve | boundary=protected_area | boundary=nature_reserve [0x16 resolution 20 continue]

There’s no attention being paid to the value of protect_class (and even less so protection_class!) and in fact the only reference I can find to protect_class is also in polygons, like this:


boundary = national_park & protect_class > 2 {set boundary=nature_reserve}
boundary = national_park [0x16 resolution 18 continue]

In other words, any “protected area” ends up being a type 0x16 polygon, which is defined in the TYP file as follows:


[_polygon]
Type=0x16
String1=0x04,Nature reserve

So apart from the mistagging issue (if I’m right about that) I think the style would also need to be modified something like the following:


leisure=nature_reserve | (boundary=protected_area & protect_class<=2) | boundary=nature_reserve [0x16 resolution 20 continue]

That’s not a real proposal, though, because the values of protect_class are really complicated. I wouldn’t want to propose something that accidentally hid a lot of real nature reserves…

Sorry about the long explanation. It’s mainly there because, as I say, I’m pretty new to this so I’m not sure which conclusions are correct and which are not. Over to the experts!

Thanks for your remarks, protect_class is the correct tag, protection_class not and should be corrected.
I also agree with you that social-protected-areas are not equal to nature reserves.
So in the styles an exception should be made for protect_class=21-29
I can adapt the code like this, I have to test if it works:

boundary=protected_area & protect_class>=21 & protect_class<=29 {delete boundary}
leisure=nature_reserve | boundary=protected_area | boundary=nature_reserve [0x16 resolution 20 continue]

Thanks, that proposal makes sense to me. I should also be able to put together a test too but it may take me a few days.

I’ll go ahead and make the tag changes in the OSM data for my area; again, this will probably be a couple of days.