Hi Ticker, the p= values are probably also reset for each partial string. These entries refer to partial string "10" and "10." 0019fec3 | 0005ac | 0e | 14 map number 0019fec4 | 0005ad | 31 13 81 | Pointer back into LBL: 011331 0019fec7 | 0005b0 | 97 93 0d | Pointer to string: BISKUPLJACA 10 0019feca | 0005b3 | 0c | name offset 12 0019fecb | 0005b4 | 01 00 00 | N sort seq p=0 s=0 | | | | | | Record 134 0019fece | 0005b7 | 0e | 14 map number 0019fecf | 0005b8 | d6 2c 81 | Pointer back into LBL: 012cd6 0019fed2 | 0005bb | fc 94 0d | Pointer to string: BOBOVIK 10 0019fed5 | 0005be | 08 | name offset 8 0019fed6 | 0005bf | 02 00 00 | R sort seq p=1 s=0 | | | | | | Record 135 0019fed9 | 0005c2 | 12 | 18 map number 0019feda | 0005c3 | 99 3a 82 | Pointer back into LBL: 023a99 0019fedd | 0005c6 | 33 6f 0e | Pointer to string: FERENSCICA 10 0019fee0 | 0005c9 | 0b | name offset 11 0019fee1 | 0005ca | 04 00 00 | R sort seq p=2 s=0 ... | | | Record 167 001a0039 | 000722 | 0e | 14 map number 001a003a | 000723 | b2 2d 81 | Pointer back into LBL: 012db2 001a003d | 000726 | 12 d8 0d | Pointer to string: ZITNA 10 001a0040 | 000729 | 06 | name offset 6 001a0041 | 00072a | 3e 00 00 | R sort seq p=31 s=0 | | | | | | Record 168 001a0044 | 00072d | 10 | 16 map number 001a0045 | 00072e | 1b 1f 81 | Pointer back into LBL: 011f1b 001a0048 | 000731 | 5a 08 0e | Pointer to string: NOVA 10. 001a004b | 000734 | 05 | name offset 5 001a004c | 000735 | 01 00 00 | N sort seq p=0 s=0 | | | | | | Record 169 001a004f | 000738 | 10 | 16 map number 001a0050 | 000739 | d5 13 81 | Pointer back into LBL: 0113d5 001a0053 | 00073c | a5 0a 0e | Pointer to string: OSOJE 10. 001a0056 | 00073f | 06 | name offset 6 001a0057 | 000740 | 02 00 00 | R sort seq p=1 s=0 | | | Record 170 001a005a | 000743 | 10 | 16 map number 001a005b | 000744 | 48 07 81 | Pointer back into LBL: 010748 001a005e | 000747 | 88 1a 0e | Pointer to string: RASTICA 10. 001a0061 | 00074a | 08 | name offset 8 001a0062 | 00074b | 04 00 00 | R sort seq p=2 s=0 | | | | | | Record 171 001a0065 | 00074e | 10 | 16 map number 001a0066 | 00074f | d1 2d 81 | Pointer back into LBL: 012dd1 001a0069 | 000752 | 61 1f 0e | Pointer to string: SRIMA 10. 001a006c | 000755 | 06 | name offset 6 001a006d | 000756 | 06 00 00 | R sort seq p=3 s=0 | | | | | | Record 172 001a0070 | 000759 | 0e | 14 map number 001a0071 | 00075a | 75 21 81 | Pointer back into LBL: 012175 001a0074 | 00075d | b1 cf 0d | Pointer to string: ULICA 10. 001a0077 | 000760 | 06 | name offset 6 001a0078 | 000761 | 08 00 00 | R sort seq p=4 s=0 Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 21. Januar 2022 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] use of --mdr7-del can break address search/street search Hi Ticker, here are the requested files. I think the numbers after s= are simply increase for each entry which refers to the same ref. A larger extract of transalpin MdrDisplay output for those MDR7 entries with s > 0: | | | Record 10 000002fe | 000036 | 01 | 1 map number 000002ff | 000037 | 80 05 80 | Pointer back into LBL: 000580 00000302 | 00003a | 00 | name offset 0 00000303 | 00003b | 04 | R sort seq p=0 s=1 | | | | | | Record 11 00000304 | 00003c | 01 | 1 map number 00000305 | 00003d | 4d 02 80 | Pointer back into LBL: 00024d 00000308 | 000040 | 00 | name offset 0 00000309 | 000041 | 08 | R sort seq p=0 s=2 | | | | | | Record 12 0000030a | 000042 | 01 | 1 map number 0000030b | 000043 | 56 05 80 | Pointer back into LBL: 000556 0000030e | 000046 | 00 | name offset 0 0000030f | 000047 | 0c | R sort seq p=0 s=3 | | | | | | Record 13 00000310 | 000048 | 01 | 1 map number 00000311 | 000049 | 60 02 80 | Pointer back into LBL: 000260 00000314 | 00004c | 00 | name offset 0 00000315 | 00004d | 10 | R sort seq p=0 s=4 | | | | | | Record 14 00000316 | 00004e | 01 | 1 map number 00000317 | 00004f | 07 06 80 | Pointer back into LBL: 000607 0000031a | 000052 | 00 | name offset 0 0000031b | 000053 | 14 | R sort seq p=0 s=5 | | | | | | Record 15 0000031c | 000054 | 01 | 1 map number 0000031d | 000055 | 84 04 80 | Pointer back into LBL: 000484 00000320 | 000058 | 00 | name offset 0 00000321 | 000059 | 18 | R sort seq p=0 s=6 Here is an extract of the Topo Adria map: 001a1cd7 | 0023c0 | 13 | 19 map number 001a1cd8 | 0023c1 | a7 0f 80 | Pointer back into LBL: 000fa7 001a1cdb | 0023c4 | 15 01 0f | Pointer to string: 2184 001a1cde | 0023c7 | 00 | name offset 0 001a1cdf | 0023c8 | 01 00 00 | N sort seq p=0 s=0 | | | | | | Record 834 001a1ce2 | 0023cb | 13 | 19 map number 001a1ce3 | 0023cc | 86 18 80 | Pointer back into LBL: 001886 001a1ce6 | 0023cf | 1b 01 0f | Pointer to string: 2184 MEDVEDICKA 001a1ce9 | 0023d2 | 00 | name offset 0 001a1cea | 0023d3 | 00 20 00 | R sort seq p=0 s=1 | | | | | | Record 835 001a1ced | 0023d6 | 13 | 19 map number 001a1cee | 0023d7 | d4 1a 80 | Pointer back into LBL: 001ad4 001a1cf1 | 0023da | 28 01 0f | Pointer to string: 2185 001a1cf4 | 0023dd | 00 | name offset 0 001a1cf5 | 0023de | 01 00 00 | N sort seq p=0 s=0 | | | | | | Record 836 001a1cf8 | 0023e1 | 13 | 19 map number 001a1cf9 | 0023e2 | 14 19 80 | Pointer back into LBL: 001914 001a1cfc | 0023e5 | 2e 01 0f | Pointer to string: 2185 CRNEC 001a1cff | 0023e8 | 00 | name offset 0 001a1d00 | 0023e9 | 00 20 00 | R sort seq p=0 s=1 | | | | | | Record 837 001a1d03 | 0023ec | 13 | 19 map number 001a1d04 | 0023ed | 6a 18 80 | Pointer back into LBL: 00186a 001a1d07 | 0023f0 | 38 01 0f | Pointer to string: 2185 DRAGANCI 001a1d0a | 0023f3 | 00 | name offset 0 001a1d0b | 0023f4 | 00 40 00 | R sort seq p=0 s=2 | | | | | | Record 838 001a1d0e | 0023f7 | 13 | 19 map number 001a1d0f | 0023f8 | 97 18 80 | Pointer back into LBL: 001897 001a1d12 | 0023fb | 44 01 0f | Pointer to string: 2185 DRENOVICA 001a1d15 | 0023fe | 00 | name offset 0 001a1d16 | 0023ff | 00 60 00 | R sort seq p=0 s=3 | | | | | | Record 839 001a1d19 | 002402 | 13 | 19 map number 001a1d1a | 002403 | 03 19 80 | Pointer back into LBL: 001903 001a1d1d | 002406 | 50 01 0f | Pointer to string: 2185 MEDVEDICKA 001a1d20 | 002409 | 00 | name offset 0 001a1d21 | 00240a | 00 80 00 | R sort seq p=0 s=4 | | | | | | Record 840 001a1d24 | 00240d | 13 | 19 map number 001a1d25 | 00240e | 20 19 80 | Pointer back into LBL: 001920 001a1d28 | 002411 | 5d 01 0f | Pointer to string: 2185 MOLVICE 001a1d2b | 002414 | 00 | name offset 0 001a1d2c | 002415 | 00 a0 00 | R sort seq p=0 s=5 | | | | | | Record 841 001a1d2f | 002418 | 13 | 19 map number 001a1d30 | 002419 | f3 18 80 | Pointer back into LBL: 0018f3 001a1d33 | 00241c | 69 01 0f | Pointer to string: 2185 PAVLJANCI 001a1d36 | 00241f | 00 | name offset 0 001a1d37 | 002420 | 00 c0 00 | R sort seq p=0 s=6 | | | | | | Record 842 001a1d3a | 002423 | 13 | 19 map number 001a1d3b | 002424 | 79 18 80 | Pointer back into LBL: 001879 001a1d3e | 002427 | 76 01 0f | Pointer to string: 2185 SIRINE 001a1d41 | 00242a | 00 | name offset 0 001a1d42 | 00242b | 00 e0 00 | R sort seq p=0 s=7 ... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 21. Januar 2022 11:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] use of --mdr7-del can break address search/street search Hi Gerd The extraInfo byte(s) could contain than 1bit sort flag, 0-4bits prefix. 0-4bits suffix. Magic 0x1e00 says how many bits the prefix is, so can find the suffix. Maybe the next 4 bits 0x1e000 say how big the suffix is so can get more info, which is the 6 you are seeing. What is the magic for the mdr7s of the 2 maps you mention; can you do the MdrSummary Ticker On Fri, 2022-01-21 at 08:54 +0000, gpetermann_muenchen@hotmail.com wrote:
Hi Ticker,
don't worry. My current thinking is that the numbers s= displayed in the mdr7 section by MdrDisplay may somehow point into Mdr32/33. I am looking at the transalpin demo map. I see a few entries in 32/33 for road names which appear after a road ref. Those have a value > 0 in s= Extract from mdr7: 0000031c | 000054 | 01 | 1 map number 0000031d | 000055 | 84 04 80 | Pointer back into LBL: 000484 00000320 | 000058 | 00 | name offset 0 00000321 | 000059 | 18 | R sort seq p=0 s=6 Extract from NetDisplay for the road with label offset 484: 00002e33 | 002dcf | 70 05 80 | Label offset: 570 (B186 DORFSTRAßE) ... 00002eb8 | 002e54 | 80 05 80 | Label offset: 580 (B186 GEWERBEGEBIET SÖLDEN) .... 00002ef3 | 002e8f | 4d 02 80 | Label offset: 24d (B186 GURGLERSTRAßE) ... 00002f43 | 002edf | 56 05 80 | Label offset: 556 (B186 KIRCHENKAR) ... 00002f59 | 002ef5 | 60 02 80 | Label offset: 260 (B186 ÖTZTAL-BUNDESSTRAßE) ... 00003013 | 002faf | 07 06 80 | Label offset: 607 (B186 ÖTZTALSTRAßE) ... 0000302c | 002fc8 | 84 04 80 | Label offset: 484 (B186 TIMMELSJOCHSTRAßE)
Problem: There are more strings in mdr32 and I have no idea how exactly the numbers are used. Entries in mdr32/33 are sorted alphabetically. In this map set they contain the words after ref B186 and all entries in MDR7 with s > 0 refer to those road labels. Also it seems that values > 0 in s= only appear with "name offset 0" mdr32: --------- MDR 32 (pointers to mdr33) -------------------------------- ----------- 00002781 | 000000 | 00 00 | Offset in mdr33: 0 00002783 | 000002 | 0c 00 | Offset in mdr33: 12 | | | mdr33 string: BUNDESSTRAßE 00002785 | 000004 | 16 00 | Offset in mdr33: 22 | | | mdr33 string: DORFSTRAßE 00002787 | 000006 | 23 00 | Offset in mdr33: 35 | | | mdr33 string: GEWERBEGEBIET 00002789 | 000008 | 30 00 | Offset in mdr33: 48 | | | mdr33 string: GURGLERSTRAßE 0000278b | 00000a | 3a 00 | Offset in mdr33: 58 | | | mdr33 string: KIRCHENKAR 0000278d | 00000c | 40 00 | Offset in mdr33: 64 | | | mdr33 string: OTZTAL 0000278f | 00000e | 4c 00 | Offset in mdr33: 76 | | | mdr33 string: OTZTALSTRAßE 00002791 | 000010 | 52 00 | Offset in mdr33: 82 | | | mdr33 string: SOLDEN | | | mdr33 string: TIMMELSJOCHSTRAßE
No idea how the data is used. My Oregon cannot find any address and shows garbage for the region name when I install the gmapsupp.img.
The Adria Topo map also seems to show s= values > 0 only for labels which contain a ref. Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 20. Januar 2022 23:00 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] use of --mdr7-del can break address search/street search
Hi Gerd
I got confused between Mdr15 (full string for gmapi) and Mdr17 (partial string for device), so what I wrote here makes little sense.
I need to think about it more. Sorry for wasting your time.
Ticker
On Thu, 2022-01-20 at 20:42 +0000, Ticker Berkin wrote:
Hi Gerd
It could be trying to represent something as follows:
For a device, there is no MDR17 string, so no possibility of using this to have index entries for parts of the street name.
A street LBL can have any number of prefix / suffix chars. Multiple mdr7 repeat records can be generated for the same label, each specifying a prefix and suffix marker count/index to indicate that part of the label to be searchable.
MdrDisplay shows these prefix/suffix indexes
Ticker
On Thu, 2022-01-20 at 20:02 +0000, Gerd Petermann wrote:
Hi Ticker,
I also wondered why these lines still exist: int bitsPrefix = (maxPrefixCount == 0) ? 0 : Integer.numberOfTrailingZeros(Integer.highestOneBit(maxPrefixCoun t) ) + 1; int bitsSuffix = (maxSuffixCount == 0) ? 0 : Integer.numberOfTrailingZeros(Integer.highestOneBit(maxSuffixCoun t) ) + 1;
The two counters are never increased in the current code. In r3968 there's some commented code which used them.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 20. Januar 2022 19:22 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] use of --mdr7-del can break address search/street search
Hi Gerd
I'm struggling to understand the possibilities of Mdr7 (ordering, partialInfo, nameOffset, string different to label, etc etc)
My initial thought about nameOffset was that it was for skipping over the shield prefix or text before the 0x1b marker.
partialInfo is very strange; it seems to be used for part of the rr flag but the code suggests it also held counts of the number of prefixes and suffixes.
Sorry - not being much use here.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev