Hi Ticker, yes, Adria topo index is for the PC, and Transalpin is gmapsupp (with just one tile). I don't know why transalpin doesn't work on my device. It's a demo map, so it probably should. mdr7 magic: yes, highest p= value in Adria Topo is p=2271, highest s is s=22, in Transalpin it is p=1 and s=6. reg. 32/33: I didn't see any effect in MapSource. My Mother has a Garmin device which helps to type street /city names in a way that it displays a keyboard where some keys are grayed out when there will be no match. Could this be the purpose for these sections? This might also explain why there are no Umlauts in 33. I first thought there's only A-Z, but in the large mdr from Nick I see repeated ' (0x27): --------- MDR 33 (unknown) ----------------------------------------------------- | | | Unknown 174608 bytes: 0a8c6a2e | 000000 | 27 27 48 4f 44 45 4e 47 | ''HODENG 0a8c6a36 | 000008 | 45 52 27 59 56 45 54 4f | ER'YVETO 0a8c6a3e | 000010 | 54 41 41 41 52 4f 4e 41 | TAAARONA 0a8c6a46 | 000018 | 42 41 44 49 45 41 42 41 | BADIEABA Gerd reg. ß instead of SS: Yes, seems Garmin doesn't use a standard method like String.toUpperCase(). I guess they have something like Sort.toUpperCase() 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 18:27 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] use of --mdr7-del can break address search/street search Hi Gerd Thanks for these. The MdrSummary for adriaTopo doesn't list sections after Mdr16, but it has populated Mdr1 subsections for Mdr20, 21 & 22. Looks like gmapi version MdrSummary for transalpine doesn't show anything after Mdr19. Looks like gmapsupp version. Could this be why it doesn't work on your device. my interpretation of mdr7 magic: adriaTopo: 12 bits for p, leaving 11 bits for s, nameOffset, U1, hasStr transalpine: 1 bit for p, leaving 6 bits for s, nameOffset, mdr17, U1 It seems as if Mdr32/33 could be prefix/suffix deletion strings and each Mdr7 record can specify one of each. These hide the matching string from the LBL. Interesting that it Garmin does: ... (B186 DORFSTRAßE) for upper case, rather than (B186 DORFSTRASSE) Ticker On Fri, 2022-01-21 at 10:55 +0000, Gerd Petermann wrote:
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(maxPrefixCo un t) ) + 1; int bitsSuffix = (maxSuffixCount == 0) ? 0 : Integer.numberOfTrailingZeros(Integer.highestOneBit(maxSuffixCo un 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 _______________________________________________ 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