January 2022 - mkgmap-dev - The mkgmap lists

Genarated NSIS languages
by Böjthe-Beyer Barna 22 Jan '22

22 Jan '22

Hi Team! 1) thanks for this wonderful program/compilator, glad that we have it! 2) I have a question: is there a way to customize the languages generated by mkgmap for the NSIS installer? Sure, we can "hack" the generated nsis file before running makensis, but if there is a "normal" method... Thanks! -BBB-

2 1

use of --mdr7-del can break address search/street search
by Gerd Petermann 22 Jan '22

22 Jan '22

Hi all, see https://files.mkgmap.org.uk/detail/547 A search in Mapsource for street name "Birkenweg" only finds "Birkenweg Foot,Unna" while it should find many more entries for cities like Altena, Fröndenberg/Ruhr, Hemer and others. The cause of the trouble is that the first road label in the map that that starts with "Birkenweg" is the "Birkenweg Foot" in Unna. Reason: With --mdr7-del=foot the label is treated like "Birkenweg" and all other roads with label "Birkenweg" in this tile are ignored because the index already contains an entry "Birkenweg" (only one entry per map is stored). This index entry will point to the label "Birkenweg Foot" in the tile, and thus only roads with that label are found. I have a few ideas how to fix this problem, but I am pretty sure that search can only work well when the real street name is stored in one of the 4 road labels (without other words or refs). Up to now the --housenumbers option forces this when the road has numbers, but mkgmap should probably always do this. If that is done the option --mdr7-del could work like this: If any of the listed words is found ignore the label for the index. Or maybe the option is obsolete and we can simply ignore the first label for the index whenever there are further labels. Gerd

5 19

Deformed polygons
by John Thorn 21 Jan '22

21 Jan '22

Sadly, it is a feature of Garmin architecture. Coordinates are held using up to 24bits (depending on the Level parameters). With 24bits that gives a resolution of about 2.5metres. Imagine drawing a map in a sheet of graph paper but the polygon and plyline corners can only be where the grid lines intersect. Other than changing the Level parameter to the maximum there is nothing you can do. On Fri, 21 Jan 2022 at 10:22, <mkgmap-dev-request(a)lists.mkgmap.org.uk> wrote: > Send mkgmap-dev mailing list submissions to > mkgmap-dev(a)lists.mkgmap.org.uk > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > or, via email, send a message with subject or body 'help' to > mkgmap-dev-request(a)lists.mkgmap.org.uk > > You can reach the person managing the list at > mkgmap-dev-owner(a)lists.mkgmap.org.uk > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mkgmap-dev digest..." > Today's Topics: > > 1. Polygon deformation (Alexis Lecanu) > > > > ---------- Forwarded message ---------- > From: Alexis Lecanu <alexis.lecanu.garmin(a)gmail.com> > To: mkgmap-dev(a)lists.mkgmap.org.uk > Cc: > Bcc: > Date: Fri, 21 Jan 2022 08:52:24 +0100 > Subject: [mkgmap-dev] Polygon deformation > Hello, I'm contacting you because I can't understand why my polygons are > deformed, I tried to find the options that could be the cause but nothing > affects the polygons. > Is it wanted directly in the algo? > I see that simple shapes like a rectangle can become a triangle or a more > complex polygon, it's a shame for the readability. > > Thank you in advance for your answer. > > > > ---- > Alexis LECANU > > https://www.facebook.com/Garmin-Connect-App-Alexis-Lecanu-395326794312827 > > If you want to pay me a beer to thank me: > https://ko-fi.com/alexislecanu > > > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

1 0

Polygon deformation
by Alexis Lecanu 21 Jan '22

21 Jan '22

Hello, I'm contacting you because I can't understand why my polygons are deformed, I tried to find the options that could be the cause but nothing affects the polygons. Is it wanted directly in the algo? I see that simple shapes like a rectangle can become a triangle or a more complex polygon, it's a shame for the readability. Thank you in advance for your answer. ---- Alexis LECANU https://www.facebook.com/Garmin-Connect-App-Alexis-Lecanu-395326794312827 If you want to pay me a beer to thank me: https://ko-fi.com/alexislecanu

3 2

elevation in bridges and tunnels
by lig fietser 20 Jan '22

20 Jan '22

Hi guys, I came across this video on youtube, where ridewithgps.com improved their elevation profiles by ignoring the underlying altititude data of tunnel and bridges: https://youtu.be/wd-wT3EeayI I found out that other route planners like brouter, cycle.travel and Osmand also ignores the surface altitude that lies above tunnels and underneath bridges, but mkgmap/Garmin does not. This leads to a much higher elevation gain or loss in the route profile than the actual ride. Is it possible for mkgmap to correct this issue, or is it hard coded in the Garmin Basecamp software?

2 5

How to display administrative boundaries / shade them?
by Craig Durkin 20 Jan '22

20 Jan '22

Hi mkgmap folks -- sorry if this is kind of a beginning question, but I can't for the life of me figure out how to get administrative boundaries (or really any arbitrary polygon) to display with mkgmap. Ideally I'd be able to lightly shade the inside of the boundary polygon, but even displaying the polygon is eluding me. An example OSM relation that I'm trying to display is Conyers, GA, USA relation ID 119584. I understand that there might be editing necessary to the style files, but it's not really clear: do I edit relations, lines, or polygons? Or all 3? Can anyone offer any tips? Thanks, Craig

3 11

Display MdrCheck fix
by Ticker Berkin 18 Jan '22

18 Jan '22

Hi Gerd Patch attached to fix offsetSize in check16 and have readVarLength() return the size. Ticker

2 1

improve appeareance of footways leading to missing buildings
by jose1711 17 Jan '22

17 Jan '22

hello all, my etrex legend has only 8 mb available for custom maps so sacrificing buildings is an obvious choice. just removing the buildings from the style however results in something like this: see that comb-shaped ways? those are usually bits leading to building entrances (here's the source: https://www.openstreetmap.org/#map=18/48.75978/17.82890) frankly, i don't really need them as they don't really carry any important information. douglas-pecker does not help here so i wonder if anyone has an idea how this can be optimized. i still want to retain the footways, just don't want them to be too "hairy". if this is not an easy task and involves too much coding then i will probably give up but before that i just wanted to ask if anyone has any idea. thank you, jose

5 4

option --mdr7-del: change or add new option?
by Gerd Petermann 17 Jan '22

17 Jan '22

Hi all, the current implementation only removes words from the right. Felix and Mike both suggested to change that so that the listed words are removed anywhere, and I think Arndt's Style would also benefit. Should I simply change the implementation and documentation or is backward compatibility important? If we want to be backward compatible we need a new option. This could be something like --mdr7-delx or --mdr7-del-all Gerd

5 6

Please try and report results of Huffman compression
by Gerd Petermann 17 Jan '22

17 Jan '22

Hi all, during the last weeks Ticker and I decoded Garmin's String compression of the global index for the PC (the *_mdr.img) . In the mdr2 branch I've coded support for that in mkgmap and I think its ready for a first beta test. It works with codepages 1250 ..1258 or 65001. I've no idea how the 2-byte pages work, but Garmin seems to support that, too. Maybe I'll work on this later. The branch version produces around 200 lines of diagnostic output to show what happens when compression is enabled. This will be changed to debug level later. The encoding is enabled by default, special option --x-no-mdr15-compression can be used to turn it off. Note that the size of the *_mdr.img file will be smaller (which is esp. intersting for those who get close to the 2G limit) Note also that a zipped *_mdr.img can and will be larger since zip cannot remove as much redundancy. Note also that this branch includes the changes from the faster-mp branch and introduces a few changes which are relavant for --lower-case maps. How to test? Install the map in MapSource and check if you see any unexpected characters in the result lists or maybe even crashes while searching. If so, please try the same input files with the --x-no-mdr15-compression to verify if this is caused by compression or maybe other changes. Please don't yet publish the maps, but let me know if you see anything unexpected. Some changes reg. lower-case in this branch are still experimental. The binary is here: https://www.mkgmap.org.uk/download/mkgmap-mdr2-r4865.zip If you see errors which are caused by compression, please attach the diagnostic output. @Ticker: Please review the source. Gerd

5 23