January 2022 - mkgmap-dev - The mkgmap lists

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

using part action with :
by 7770 02 Jan '22

02 Jan '22

Hi. On page 16 and 17 in the styles manual the part opreration is mentioned. What is the correct syntax to split a string by colon : ? I tried something like {set name='${name|part:"::-1"}'} to get the last portion after a : . but that was not allowed. Regards Karl

2 1

Fix and augment sort definitions
by Ticker Berkin 02 Jan '22

02 Jan '22

Hi Gerd In the resource/sort/cp*.txt sort definitions, I notices that all but cp1252.txt/Western European and cp65001.txt/unicode don't handle "#" correctly and cp1252.txt/Western European and cp1254.txt/Turkish don't add expansions for all their double-characters. Patch attached that fixes these problems, makes the layout consistent, adds useful information to README and removes the id2 current value, which just gets out-of-date. All the id2 values are incremented if appropriate. The "#" fix might be the reason why searching for street names starting with # didn't work for code-page=0 / format6 Adding the "ß" expansion might be a step towards resolving the problem with searching and --lower-case that the subject of discussion a year or so ago - I can't find the thread. Ticker

1 0

branch mdr2 now implements Huffman encoding
by Gerd Petermann 02 Jan '22

02 Jan '22

Hi all, my outlook account was locked, don't know yet why. I am writing this from an alternative account while waiting for Microsoft to fix that issue... I've now committed a first working version in the mdr2 branch: https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4841 https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4882 Don't expect anything drastic. The size of the MDR15 section is typically reduced by 33%, The rest of the index sections is not changed, a small MDR16 section is added. Gerd

1 0

Building Huffman tree
by Ticker Berkin 01 Jan '22

01 Jan '22

Hi Gerd Some thoughts on this: Dividing the \0 count by some factor between 3 and 6 should reduce the overall length of the strings. This is because there will be 0..7 bits free after each string To make the canonical tree: after using the standard algo to make a normal tree, just remember the count at each level and chuck the tree away. Then simply allocate chars, in decreasing frequency order, in previously levels, from root (and maybe high to low), much the same way as the decoder handles levels 6 and above. It might be that if you start with ordered list when building the initial tree, and get the inequalities right for when sums of lower levels are equal, you get the canonical tree, but this is just a guess. Happy new year Ticker

2 4