use of --mdr7-del can break address search/street search
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
Hi all, I think I found a solution that works well (at least for Arndt) The attached patch mdr7-del3.patch changes mkgmap so that 1) For the global index, the --mdr7-del option now lists "stop index" words. If any of the listed words appears in a road label the label is not added to the global index. 2) each road gets a label from the field mkgmap:street (if the road didn't have any label mkgmap adds a blank label and a 2nd label with the name). If the road already had 4 labels and none matches the value in mkgmap:street the last label is replaced. A similar logic was already in the housenumber processing, but it was only executed for roads with housenumbers. These two changes fix the problems with street/address search for Arndt's "Speiche" style. He told me that he wants the long name in the routing directions but only the road name in the address search. The good thing is that the patch reduces both the tile size and the index size and MdrCheck no longer complains about any road. Felix might not be so happy with this, as he wrote that he wants to be able to search for street names that contain e.g. route relation names. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Mittwoch, 19. Januar 2022 09:01 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] use of --mdr7-del can break address search/street search 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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd I'm trying understand all this, so maybe what I'm trying to say here is rubbish. How is it that --split-name-index didn't also break Find > Street select list. If it is required that Mdr7 index entries refer to a label, then, maybe, can have multiple index entries to the same label with different starting positions, indicated by [out]NameOffset. These shouldn't be deduped against apparently the same partial name from elsewhere. It avoids the need for the tile builder to adjusting one of the 4 labels. A disadvantage is that each duplicate entry runs to the end of the label. I don't understand what the Mdr7 repeat flag is supposed to indicate. Also, if MDR7_HAS_STRING, does the offset work in this Ticker
Hi Ticker, the major difference between the (unpatched) --mdr7-del and the --split-name-index processing is that --mdr7-del takes the original label and changes the content before the index calculation starts. Later, the sorted positions don't match with the original labels and Garmin cannot find the label that the list shows. --split-name-index just calculates positions based on the full label. This works because we don't change the label. The repeat flags are probably used to decide which tiles have to be read to find all candidates for a given index entry. I've attached an alternative patch which applies the --mdr7-del list later. For each (partial) string the first (!) word is checked against --mdr7-del list. If found, the partial label is ignored. I guess that's what you meant? This also fixes the index errors but doesn't change the index size. I'll need time to find out what I like more and how this works when labels start with a word in --mdr7-del list. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 19. Januar 2022 13:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] use of --mdr7-del can break address search/street search Hi Gerd I'm trying understand all this, so maybe what I'm trying to say here is rubbish. How is it that --split-name-index didn't also break Find > Street select list. If it is required that Mdr7 index entries refer to a label, then, maybe, can have multiple index entries to the same label with different starting positions, indicated by [out]NameOffset. These shouldn't be deduped against apparently the same partial name from elsewhere. It avoids the need for the tile builder to adjusting one of the 4 labels. A disadvantage is that each duplicate entry runs to the end of the label. I don't understand what the Mdr7 repeat flag is supposed to indicate. Also, if MDR7_HAS_STRING, does the offset work in this Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, I think mdr7-del4.patch works better for Felix as it is closer to the documented behaviour (doesn't completely ignore labels with words in mdr7-del). It works quite well with the --split-name-index option, without it the results might be bad when labels start with a word that occurs in mdr7-del list. mdr7-del3.patch works better for Arndt because his style adds various tag values to road labels, but not route relation names. For him it would even work to ignore the first label when there are more labels. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Mittwoch, 19. Januar 2022 16:09 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] use of --mdr7-del can break address search/street search Hi Ticker, the major difference between the (unpatched) --mdr7-del and the --split-name-index processing is that --mdr7-del takes the original label and changes the content before the index calculation starts. Later, the sorted positions don't match with the original labels and Garmin cannot find the label that the list shows. --split-name-index just calculates positions based on the full label. This works because we don't change the label. The repeat flags are probably used to decide which tiles have to be read to find all candidates for a given index entry. I've attached an alternative patch which applies the --mdr7-del list later. For each (partial) string the first (!) word is checked against --mdr7-del list. If found, the partial label is ignored. I guess that's what you meant? This also fixes the index errors but doesn't change the index size. I'll need time to find out what I like more and how this works when labels start with a word in --mdr7-del list. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 19. Januar 2022 13:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] use of --mdr7-del can break address search/street search Hi Gerd I'm trying understand all this, so maybe what I'm trying to say here is rubbish. How is it that --split-name-index didn't also break Find > Street select list. If it is required that Mdr7 index entries refer to a label, then, maybe, can have multiple index entries to the same label with different starting positions, indicated by [out]NameOffset. These shouldn't be deduped against apparently the same partial name from elsewhere. It avoids the need for the tile builder to adjusting one of the 4 labels. A disadvantage is that each duplicate entry runs to the end of the label. I don't understand what the Mdr7 repeat flag is supposed to indicate. Also, if MDR7_HAS_STRING, does the offset work in this Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, thought again about the remark reg. MDR7_HAS_STRING. With the mdr7-del4.patch we can add strings to Mdr15 section which may never used because no index entry will show the corresponding label. So, mdr7-del4.patch is too simple as it wastes space in the PC index. Also I have big problems to document what the option --mdr7-del means when this patch is applied :( Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Mittwoch, 19. Januar 2022 16:09 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] use of --mdr7-del can break address search/street search Hi Ticker, the major difference between the (unpatched) --mdr7-del and the --split-name-index processing is that --mdr7-del takes the original label and changes the content before the index calculation starts. Later, the sorted positions don't match with the original labels and Garmin cannot find the label that the list shows. --split-name-index just calculates positions based on the full label. This works because we don't change the label. The repeat flags are probably used to decide which tiles have to be read to find all candidates for a given index entry. I've attached an alternative patch which applies the --mdr7-del list later. For each (partial) string the first (!) word is checked against --mdr7-del list. If found, the partial label is ignored. I guess that's what you meant? This also fixes the index errors but doesn't change the index size. I'll need time to find out what I like more and how this works when labels start with a word in --mdr7-del list. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 19. Januar 2022 13:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] use of --mdr7-del can break address search/street search Hi Gerd I'm trying understand all this, so maybe what I'm trying to say here is rubbish. How is it that --split-name-index didn't also break Find > Street select list. If it is required that Mdr7 index entries refer to a label, then, maybe, can have multiple index entries to the same label with different starting positions, indicated by [out]NameOffset. These shouldn't be deduped against apparently the same partial name from elsewhere. It avoids the need for the tile builder to adjusting one of the 4 labels. A disadvantage is that each duplicate entry runs to the end of the label. I don't understand what the Mdr7 repeat flag is supposed to indicate. Also, if MDR7_HAS_STRING, does the offset work in this Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, sorry, it seems I still haven't understood how the index structure works. With the patch mdr7-del4.patch mkgmap creates an index which makes MdrCheck happy, but MapSource typically says "no item found" when I pick one of the entries that start with a word which appears in the mdr7-del list. So, both mkmap and MdrCheck are probably wrong. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 20. Januar 2022 10:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] use of --mdr7-del can break address search/street search Hi Ticker, thought again about the remark reg. MDR7_HAS_STRING. With the mdr7-del4.patch we can add strings to Mdr15 section which may never used because no index entry will show the corresponding label. So, mdr7-del4.patch is too simple as it wastes space in the PC index. Also I have big problems to document what the option --mdr7-del means when this patch is applied :( Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Mittwoch, 19. Januar 2022 16:09 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] use of --mdr7-del can break address search/street search Hi Ticker, the major difference between the (unpatched) --mdr7-del and the --split-name-index processing is that --mdr7-del takes the original label and changes the content before the index calculation starts. Later, the sorted positions don't match with the original labels and Garmin cannot find the label that the list shows. --split-name-index just calculates positions based on the full label. This works because we don't change the label. The repeat flags are probably used to decide which tiles have to be read to find all candidates for a given index entry. I've attached an alternative patch which applies the --mdr7-del list later. For each (partial) string the first (!) word is checked against --mdr7-del list. If found, the partial label is ignored. I guess that's what you meant? This also fixes the index errors but doesn't change the index size. I'll need time to find out what I like more and how this works when labels start with a word in --mdr7-del list. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 19. Januar 2022 13:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] use of --mdr7-del can break address search/street search Hi Gerd I'm trying understand all this, so maybe what I'm trying to say here is rubbish. How is it that --split-name-index didn't also break Find > Street select list. If it is required that Mdr7 index entries refer to a label, then, maybe, can have multiple index entries to the same label with different starting positions, indicated by [out]NameOffset. These shouldn't be deduped against apparently the same partial name from elsewhere. It avoids the need for the tile builder to adjusting one of the 4 labels. A disadvantage is that each duplicate entry runs to the end of the label. I don't understand what the Mdr7 repeat flag is supposed to indicate. Also, if MDR7_HAS_STRING, does the offset work in this 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
Hi Ticker, It seems that we must write an Mdr7Record with outNameOffset==0 if we also want to write other entries with outNameOffset>0. If that is the case MdrCheck should verify that. Another problem with the mdr7-del4.patch: The code for --split-name-index logic doesn't only split at ' ' (space), it has a different logic which also splits at characters like '-', ':' etc Attached is an improved patch which works around these problems. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 20. Januar 2022 12:40 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] use of --mdr7-del can break address search/street search Hi Ticker, sorry, it seems I still haven't understood how the index structure works. With the patch mdr7-del4.patch mkgmap creates an index which makes MdrCheck happy, but MapSource typically says "no item found" when I pick one of the entries that start with a word which appears in the mdr7-del list. So, both mkmap and MdrCheck are probably wrong. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 20. Januar 2022 10:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] use of --mdr7-del can break address search/street search Hi Ticker, thought again about the remark reg. MDR7_HAS_STRING. With the mdr7-del4.patch we can add strings to Mdr15 section which may never used because no index entry will show the corresponding label. So, mdr7-del4.patch is too simple as it wastes space in the PC index. Also I have big problems to document what the option --mdr7-del means when this patch is applied :( Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Mittwoch, 19. Januar 2022 16:09 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] use of --mdr7-del can break address search/street search Hi Ticker, the major difference between the (unpatched) --mdr7-del and the --split-name-index processing is that --mdr7-del takes the original label and changes the content before the index calculation starts. Later, the sorted positions don't match with the original labels and Garmin cannot find the label that the list shows. --split-name-index just calculates positions based on the full label. This works because we don't change the label. The repeat flags are probably used to decide which tiles have to be read to find all candidates for a given index entry. I've attached an alternative patch which applies the --mdr7-del list later. For each (partial) string the first (!) word is checked against --mdr7-del list. If found, the partial label is ignored. I guess that's what you meant? This also fixes the index errors but doesn't change the index size. I'll need time to find out what I like more and how this works when labels start with a word in --mdr7-del list. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 19. Januar 2022 13:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] use of --mdr7-del can break address search/street search Hi Gerd I'm trying understand all this, so maybe what I'm trying to say here is rubbish. How is it that --split-name-index didn't also break Find > Street select list. If it is required that Mdr7 index entries refer to a label, then, maybe, can have multiple index entries to the same label with different starting positions, indicated by [out]NameOffset. These shouldn't be deduped against apparently the same partial name from elsewhere. It avoids the need for the tile builder to adjusting one of the 4 labels. A disadvantage is that each duplicate entry runs to the end of the label. I don't understand what the Mdr7 repeat flag is supposed to indicate. Also, if MDR7_HAS_STRING, does the offset work in this 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
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
Hi Ticker, I also wondered why these lines still exist: int bitsPrefix = (maxPrefixCount == 0) ? 0 : Integer.numberOfTrailingZeros(Integer.highestOneBit(maxPrefixCount)) + 1; int bitsSuffix = (maxSuffixCount == 0) ? 0 : Integer.numberOfTrailingZeros(Integer.highestOneBit(maxSuffixCount)) + 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
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(maxPrefixCount)) + 1; int bitsSuffix = (maxSuffixCount == 0) ? 0 : Integer.numberOfTrailingZeros(Integer.highestOneBit(maxSuffixCount)) + 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
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(maxPrefixCount) ) + 1; int bitsSuffix = (maxSuffixCount == 0) ? 0 : Integer.numberOfTrailingZeros(Integer.highestOneBit(maxSuffixCount) ) + 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
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(maxPrefixCount) ) + 1; int bitsSuffix = (maxSuffixCount == 0) ? 0 : Integer.numberOfTrailingZeros(Integer.highestOneBit(maxSuffixCount) ) + 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
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
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
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
Hi Ticker, one more extract which probably explains more since p= values are not in a simple order. No idea if the screenshot shows any of this extra info or if the search result is different because of this extra info. I guess you have to play with it... | | | Record 1066 001a26da | 002dc3 | 0e | 14 map number 001a26db | 002dc4 | 86 02 81 | Pointer back into LBL: 010286 001a26de | 002dc7 | 1a da 0d | Pointer to string: ZUKVE 28. ULICA 001a26e1 | 002dca | 06 | name offset 6 001a26e2 | 002dcb | 04 00 00 | R sort seq p=2 s=0 | | | | | | Record 1067 001a26e5 | 002dce | 12 | 18 map number 001a26e6 | 002dcf | 58 6a 82 | Pointer back into LBL: 026a58 001a26e9 | 002dd2 | 7a 48 0e | Pointer to string: 29 001a26ec | 002dd5 | 00 | name offset 0 001a26ed | 002dd6 | 01 00 00 | N sort seq p=0 s=0 | | | | | | Record 1068 001a26f0 | 002dd9 | 12 | 18 map number 001a26f1 | 002dda | cd 1a 80 | Pointer back into LBL: 001acd 001a26f4 | 002ddd | 7d 48 0e | Pointer to string: 29 001a26f7 | 002de0 | 00 | name offset 0 001a26f8 | 002de1 | 04 00 00 | R sort seq p=2 s=0 | | | | | | Record 1069 001a26fb | 002de4 | 12 | 18 map number 001a26fc | 002de5 | 16 2a 80 | Pointer back into LBL: 002a16 001a26ff | 002de8 | 81 48 0e | Pointer to string: 29 KOLODVORSKA CESTA 001a2702 | 002deb | 00 | name offset 0 001a2703 | 002dec | 04 20 00 | R sort seq p=2 s=1 | | | | | | Record 1070 001a2706 | 002def | 0e | 14 map number 001a2707 | 002df0 | 0c 2d 81 | Pointer back into LBL: 012d0c 001a270a | 002df3 | 70 95 0d | Pointer to string: BOBOVIK 29 001a270d | 002df6 | 08 | name offset 8 001a270e | 002df7 | 02 00 00 | R sort seq p=1 s=0 | | | | | | Record 1071 001a2711 | 002dfa | 0e | 14 map number 001a2712 | 002dfb | 68 14 81 | Pointer back into LBL: 011468 001a2715 | 002dfe | 94 ac 0d | Pointer to string: LUCICA 29 001a2718 | 002e01 | 07 | name offset 7 001a2719 | 002e02 | 06 00 00 | R sort seq p=3 s=0 | | | | | | Record 1072 001a271c | 002e05 | 0e | 14 map number 001a271d | 002e06 | f8 1f 81 | Pointer back into LBL: 011ff8 001a2720 | 002e09 | 1b ba 0d | Pointer to string: PREZIDA 29 001a2723 | 002e0c | 08 | name offset 8 001a2724 | 002e0d | 08 00 00 | R sort seq p=4 s=0 | | | | | | Record 1073 001a2727 | 002e10 | 0e | 14 map number 001a2728 | 002e11 | c0 2b 81 | Pointer back into LBL: 012bc0 001a272b | 002e14 | c3 ca 0d | Pointer to string: STRAZA 29 001a272e | 002e17 | 07 | name offset 7 001a272f | 002e18 | 0a 00 00 | R sort seq p=5 s=0 | | | | | | Record 1074 001a2732 | 002e1b | 10 | 16 map number 001a2733 | 002e1c | 7b 8c 81 | Pointer back into LBL: 018c7b 001a2736 | 002e1f | 3b 26 0e | Pointer to string: ULICA 29 001a2739 | 002e22 | 06 | name offset 6 001a273a | 002e23 | 0c 00 00 | R sort seq p=6 s=0 | | | | | | Record 1075 001a273d | 002e26 | 0e | 14 map number 001a273e | 002e27 | 0a 16 81 | Pointer back into LBL: 01160a 001a2741 | 002e2a | 6c d8 0d | Pointer to string: ZITNA 29 001a2744 | 002e2d | 06 | name offset 6 001a2745 | 002e2e | 0e 00 00 | R sort seq p=7 s=0 | | | | | | Record 1076 001a2748 | 002e31 | 10 | 16 map number 001a2749 | 002e32 | 2c 32 81 | Pointer back into LBL: 01322c 001a274c | 002e35 | 92 ec 0d | Pointer to string: 29 LISTOPADA 1918 001a274f | 002e38 | 00 | name offset 0 001a2750 | 002e39 | 01 00 00 | N sort seq p=0 s=0 | | | | | | Record 1077 001a2753 | 002e3c | 0e | 14 map number 001a2754 | 002e3d | fb 22 81 | Pointer back into LBL: 0122fb 001a2757 | 002e40 | 7a d0 0d | Pointer to string: ULICA 29. 001a275a | 002e43 | 06 | name offset 6 001a275b | 002e44 | 01 00 00 | N sort seq p=0 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 12:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] use of --mdr7-del can break address search/street search 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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
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
participants (5)
-
Arndt Röhrig -
Gerd Petermann -
Gerd Petermann
-
gpetermann_muenchen＠hotmail.com
-
Ticker Berkin