Worldwide routable Garmin maps: Missing/incorrect feature requests

ligfietser · 2018-12-26T08:36:07.000Z

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.

Russ_McD · 2018-12-27T01:59:29.000Z

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.

iay · 2019-07-15T17:32:36.000Z

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?

ligfietser · 2019-07-15T18:02:09.000Z

yes please go ahead and drop them here
yes, the latest style from github will be processed, no need to contact him
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

iay · 2019-07-15T20:10:54.000Z

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!

ligfietser · 2019-07-16T17:46:11.000Z

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]

iay · 2019-07-16T18:44:48.000Z

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.

ligfietser · 2019-07-17T07:09:17.000Z

Ian,
I’ve tested it and committed the changes into github, so it will be implemented in future updates, thanks!

iay · 2019-07-17T08:12:27.000Z

Fantastic. I figured out how to get JOSM to show me the other local cases and have uploaded a changeset fixing those.

iay · 2019-10-24T13:16:16.000Z

ligfietser:

yes, the latest style from github will be processed, no need to contact him

The GitHub style was changed three months ago, but I’m still seeing the same issue in the Garmin.osm maps, as of the set from 2019-10-18. So the data is being updated, but it doesn’t look like the style has been. Is there anything we can do about that?

ligfietser · 2019-10-26T08:35:31.000Z

Hi iay,
Seems my changes in the style

boundary=protected_area & protect_class>=21 & protect_class<=29 {delete boundary}

don’t seem to work as expected. I have to figure out why and contact Lambertus. Thanks for reporting!

ligfietser · 2019-11-12T12:20:13.000Z

@Ian, I have asked it weeks ago but unfortunately Lambertus still does not respond and has not fixed/updated the styles from Github.
Better mail him directly or try another map provider.

Since the github styles are not updated anymore I do not see any point to maintain this either (except for my own maps) and will make this topic unsticky.

Beddhist · 2019-11-12T12:23:14.000Z

Thanks for all the work you have put into this over the years.

Regards,
Peter.

iay · 2019-11-13T17:02:42.000Z

ligfietser:

@Ian, I have asked it weeks ago but unfortunately Lambertus still does not respond and has not fixed/updated the styles from Github.
Better mail him directly or try another map provider.

If he isn’t responding to you, I don’t think he is likely to respond to me. In any case, it’s not a good long term situation.

Since the github styles are not updated anymore I do not see any point to maintain this either (except for my own maps) and will make this topic unsticky.

I understand your point of view, and I think I will look into building my own maps using your style as well. I hope you’ll keep your GutHub repository up, at least.

At one point I had something that almost reproduced the ones from garmin.osm… they looked more compressed horizontally in the BaseCamp application, and I think the difference was probably something to do with the options I was using. I can probably build something from there.

I may have asked this before, but are the scripts used by garmin.osm avaiable publicly somewhere? That would probably show up the difference pretty quickly.

ligfietser · 2019-11-13T17:31:38.000Z

@Beddhist: you’re welcome, thank you too
@Ian: yes it will remain in the github repository. Btw what do you mean with compressed? Do you mean the projection angle, at certain latitudes the maps can look distorted? You can either set this with Javawa GMTK or in Mapsource. Scripts of garmin.openstreetmap.nl are not available but the mkgmap options I have posted on github.

muralito · 2019-11-13T20:26:41.000Z

iay:

At one point I had something that almost reproduced the ones from garmin.osm… they looked more compressed horizontally in the BaseCamp application, and I think the difference was probably something to do with the options I was using. I can probably build something from there.

I may have asked this before, but are the scripts used by garmin.osm avaiable publicly somewhere? That would probably show up the difference pretty quickly.

The styles used by this scripts https://proyectos.ingeniovirtual.com.ar/projects/garmin-osm/repository mimics the osm site old style (when motorways were blue)

iay · 2019-11-22T14:55:30.000Z

ligfietser:

Btw what do you mean with compressed? Do you mean the projection angle, at certain latitudes the maps can look distorted? You can either set this with Javawa GMTK or in Mapsource. Scripts of garmin.openstreetmap.nl are not available but the mkgmap options I have posted on github.

That was probably too vague for people to understand what I was saying.

I built a map for my area using your styles and mkgmap options from github. I loaded this map as well as the garmin.openstreetmap.org map for the same area (well, actually for the whole of the UK, which may be relevant) into Garmin Basecamp on my Mac.

The results were almost, but not quite, identical. The most obvious difference was that although a given number of pixels vertically on the screen seemed to correspond to the same set of features in both maps, that wasn’t true horizontally: one map was compressed horizontally relative to the other, so that the same screen distance corresponded to more features on one map than on the other.

So close!

I did play around with JaVaWa GMTK a while back but I don’t really understand the projection angle thing. It’s also something I have to fire up a virtual machine to run, as it’s a 32-bit application and Macs have gone 64-bit-only now. Mapsource is, I think, Windows-only? I’ve also seen a lot of posts that imply that the projection angle is set in the Windows registry, which obviously isn’t going to apply…

I said the fact that my test map was just for the area around my city might be relevant. I’ve seen posts implying that the projection angle Basecamp picks in the absence of an explicit setting depends on the area covered by the map. So my problem may just go away if I make my own map of the whole UK. I will have to see if I can get some time to try that.

(I say “my problem” here, but it’s not really an issue in practice as it’s only a small variation between maps… but it tells me I’m not understanding something that might be important later, which bugs me a bit.)

Any other thoughts welcome.

ligfietser · 2019-11-22T15:11:57.000Z

Ah ok, so that’s the projection angle issue, you can’t set it in mkgmap, it is somewhere stored in the Basecamp settings.
Don’t know how to change that, you have to mail Javawa, he is an expert and familiar with Macs.

iay · 2019-11-22T15:20:37.000Z

ligfietser:

Ah ok, so that’s the projection angle issue, you can’t set it in mkgmap, it is somewhere stored in the Basecamp settings.
Don’t know how to change that, you have to mail Javawa, he is an expert and familiar with Macs.

I think I did mail him about something six months or so back. I then found a page on his web site that says he had a stroke a couple of years back and that’s why he isn’t maintaining his programs, so I felt bad about bothering him again. Is he in fact still active in the community?

ligfietser · 2019-11-23T00:00:32.000Z

Yes, he is still active on the Dutch gps.nl forum, maybe you can search for a solution there or even post a question, I dont think they dont mind that you write it in English there: https://forum.gps.nl/viewforum.php?f=122