- mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] [mkgmap-svn] Commit r4854: - fix possible error when negativ index was written to lookup table
by Ticker Berkin 10 Jan '22

10 Jan '22

Hi Gerd Just starting to read the new code more carefully and a few comments: In Mdr17 the following line should be deleted: len = (len << 1) + 1; Mdr15 is not written forDevice so can skip all the compression stuff. Have you seen an example with unicode. There seem to be too many assumption about fixed/8-bit charsets to attempt compression. In Mdr15.createString, for compressed can just use ++nextOffset, the string length is meaningless Does sizes.getStrOffSize() need fixing after the final forms of the strings have been written? Will look at the nitty-gritty detail next. Ticker On Sun, 2022-01-09 at 11:03 +0000, svn commit wrote: > Version mkgmap-r4854 was committed by gerd on Sun, 09 Jan 2022 > BRANCH: mdr2 > - fix possible error when negativ index was written to lookup table > - rename initBits to lookupBits > - use common code for variable length integers in MDR16 and Mdr17 > - simplify code, add comments > to be continued... > > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4854 > _______________________________________________ > mkgmap-svn mailing list > To unsubscribe send an mail to mkgmap-svn-leave(a)lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn

2 4

LBL file encoding - Huffman
by Ticker Berkin 10 Jan '22

10 Jan '22

It looks like the LBL file could be Huffman compressed with an ENCODING value of 11. Is there scope for having the new Huffman logic with app/labelenc/CharacterEncoder /CharacterDecoder interface? Ticker

2 1

Commit r4855: improve documentation, esp. about --mdr7-del (options2.patch by Mike Baggaley)
by svn commit 10 Jan '22

10 Jan '22

Version mkgmap-r4855 was committed by gerd on Mon, 10 Jan 2022 improve documentation, esp. about --mdr7-del (options2.patch by Mike Baggaley) http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4855

1 0

Minor documentation patch
by Mike Baggaley 09 Jan '22

09 Jan '22

Hi Gerd, Please find attached a minor documentation patch. Cheers, Mike

2 2

Commit r4845: merge from faster-mp branch
by svn commit 07 Jan '22

07 Jan '22

Version mkgmap-r4845 was committed by gerd on Wed, 05 Jan 2022 merge from faster-mp branch - don't render natural=coastline in lines - implement faster (but possibly less reliable) algorithm to render complex multipolygons - don't render MP without tags (old code did that when all tags were removed because they did not appear in style rules, see field tagsIncomplete) http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4845

3 16

Commit r4850: revert merge from faster-mp branch, causes crashes in some maps
by svn commit 06 Jan '22

06 Jan '22

Version mkgmap-r4850 was committed by gerd on Thu, 06 Jan 2022 revert merge from faster-mp branch, causes crashes in some maps http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4850

1 0

Re: [mkgmap-dev] [mkgmap-svn] Commit r4848: catch some special cases which caused infinite loop in mkgmap or wrong data in MDR16 if there is not much data
by Ticker Berkin 06 Jan '22

06 Jan '22

Hi Gerd Did the '5' nibble in byte 2 indicate the size of lookup table? if so, could reduce the table size so it overflows. I assume that setting byte 3 to <= table size didn't work Ticker On Thu, 2022-01-06 at 09:25 +0000, svn commit wrote: > Version mkgmap-r4848 was committed by gerd on Thu, 06 Jan 2022 > BRANCH: mdr2 > catch some special cases which caused infinite loop in mkgmap or > wrong data in MDR16 if there is not much data > in the index > - I don't know yet what Garmin expects when there are very few > characters in the Huffman tree so that all fit into the lookup table. > Maybe this is what the unknown flag in the initial bits field is > about > - don't try to encode with invalid data in mdr16 > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4848 > _______________________________________________ > mkgmap-svn mailing list > To unsubscribe send an mail to mkgmap-svn-leave(a)lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn

2 1

do people think mkgmap tests pass?
by Greg Troxel 05 Jan '22

05 Jan '22

(After doing other things for a long time, I'm updating spliter, mkgmap, and data prepartory to building new img files.) I ran the mkgmap tests, and got some failures, 7 in args and 2 others. I am using NetBSD, but that shouldn't matter. Do people think "ant test" gets a clean pass with the current svn? If so I can send info about the failing tests. Thanks, Greg

2 3

Error in MdrCheck?
by Gerd Petermann 04 Jan '22

04 Jan '22

Hi devs, I think there is a bug in MdrCheck, probably also in other Check programs. The program doesn't read the SRT file content from the map, instead it uses the corresponding data from mkgmap. If the builtin sort order in mkgmap doesn't match the SRT file content the program will report errors about wrong order or missing repeat flags etc. I guess this explains why MdrCheck complains about the Garmin demo map for Turkey? I once started to implement a SrtFileReader but I don't know if that can be used instead. Gerd

3 10

how does subst work?
by 7770 02 Jan '22

02 Jan '22

Hi. Apologize forthis long email, there are three parts to make it easier to read. Mkgmap version 4839 is used. I am trying to replace a portion of a name. All of this happens for points and after the a line (same as in default style) that includes: include 'inc/name'; 1. First one question, are all the lines in the included file processed at the point of include 'inc/name'; or are they processed last? 2. In my case i have points which have the operator tag and a name tag. so they are affected by the include, by this code: operator=* & brand!=* { name '${operator}: ${ref} ${name}' | '${operator}: ${name}' | '${operator}: ${ref}' | '${operator}' | '${ref}' } in my case the name is set as '${operator}: ${name}'. For a few scenarios, where the operator string is too long to make good sense, i am trying to later (after the place of the include line) remove the opreator part, but i can't get it working wery well. The rule i try looks like this: amenity=shelter & shelter_type=basic_hut & (access!=private & access!=no) {set name='${name|subst:"${operator} =>"}'} [0x3913 resolution 20] Say the name is TheWildernessHut If the ${operator} tag is empty, the result becomes: TheWildernessHut =>"} (which is not good looking). If there is some value in the ${operator} tag the action block does not seem replace anything. Even more strangely, i tested make a replacement of some fixed value, it will not update the name in case the name was altered by the include section, only name tags that were not previously altered seem to be updated. Exmaple (will not update if the name was altered earlier): amenity=shelter & shelter_type=basic_hut & (access!=private & access!=no) {set name='${name|subst:"The=>"}'} [0x3913 resolution 20] I have checked that there isn't any rule earlier that will pick up the amenity=shelter & shelter_type=basic_hut & (access!=private & access!=no) , and the type 0x3913 is set correctly and shown when apply the TYP file. I also tried hardcoding a name for these patterns, that also works just well. Did i miss something else? 3. i use --add-pois-to-areas. Points which are generated from areas, does not seem to be affected by any action block for points, but the TYP is set properly. Is this how it is intended to work? Example: I have a amenity=shelter & shelter_type=basic_hut, this is drawn as a polygon. The rules for this particular structure are only applied in the points style. The TYP is set just well for the point added by --add-pois-to-areas, but it seems i can not alter the name with an action block. Regards Karl

2 3