LBL subfile details
Hi, Here are some findings that i can not manage to code in java... In mkgmap the text between the header and the first lbl section is hardcoded to the string 'mkgmap'. This section is defined at the end of the header: LBLHDR@0xB0 - 4 byte Text section begin LBLHDR@0xB4 - 4 byte Text section length (INFO_LEN in mkgmap) These values are hardcoded in mkgmap and i do not know how to change that code. It should be converted to something as the other subsections. In all original files the text is 'American'. In the source it is commented as "// Sort descriptor ??? ...". I could speculate that this is kind of dictionary name(like 'American English'). Another finding is (when the texts are coded in 6bits) that the first byte of LBL1 is 0xFF(in Metro Guide) which is decoded as 0x3F == 'End Marker'. In mkgmap it is 0x00 that i think is not correct. All elements that have no name have lbl1 pointer to this end marker so it should be 0xFF. If there are points for the cities and LBL1,2,3,4 are filled in the overview map img, menu Find->Find Places has working City tab in MapSource. Maybe overview img participate in the indexing in some way? Best Regards, Anton Todorov
I could speculate that this is kind of dictionary name(like 'American English').
I dont think so. The sorting order is imho defined in the SRT subfile. Therin are defined some properties for characters of the used codepage 1251. I think the information has to do something with replacing accented characters and the sorting order. I dont think that the etrex units have all dictionaries on board, from which they choose one. The information has to be supplied with the img.
On 23/09/09 15:52, Anton Todorov wrote:
Here are some findings that i can not manage to code in java... In mkgmap the text between the header and the first lbl section is hardcoded to the string 'mkgmap'. This section is defined at the end
original files the text is 'American'. In the source it is commented as "// Sort descriptor ??? ...". I could speculate that this is kind of dictionary name(like 'American English'). Another finding is
So that would explain what Sort Descriptor meant. All cgpsmapper created files just have a string like 'map created with cgpsmapper' which is why mkgmap ones just have the hardwired string in them.
(when the texts are coded in 6bits) that the first byte of LBL1 is 0xFF(in Metro Guide) which is decoded as 0x3F == 'End Marker'. In mkgmap it is 0x00 that i think is not correct. All elements that have no name have lbl1 pointer to this end marker so it should be 0xFF. [...]
OK, I believe this. But, have you noticed any problems caused by it though?
[...] If there are points for the cities and LBL1,2,3,4 are filled in the overview map img, menu Find->Find Places has working City tab in MapSource. Maybe overview img participate in the indexing in some
Ah ha, that is interesting. I did recently notice that the trip and waypoint map that came with my GPS had city search even though it does not have the global index file. The work I've started on the global index will also allow us to create a better overview map too so we could do this then. ..Steve
From: Steve Ratcliffe <steve@parabola.me.uk> On 23/09/09 15:52, Anton Todorov wrote:
Here are some findings that i can not manage to code in java... In mkgmap the text between the header and the first lbl section is hardcoded to the string 'mkgmap'. This section is defined at the end
original files the text is 'American'. In the source it is commented as "// Sort descriptor ??? ...". I could speculate that this is kind of dictionary name(like 'American English'). Another finding is
So that would explain what Sort Descriptor meant. All cgpsmapper created files just have a string like 'map created with cgpsmapper' which is why mkgmap ones just have the hardwired string in them.
As I wrote it is my toughts about the meaning of the exact text, but in all original files it is same. Even on an old MG Spain for example...
(when the texts are coded in 6bits) that the first byte of LBL1 is 0xFF(in Metro Guide) which is decoded as 0x3F == 'End Marker'. In mkgmap it is 0x00 that i think is not correct. All elements that have no name have lbl1 pointer to this end marker so it should be 0xFF. [...]
OK, I believe this. But, have you noticed any problems caused by it though?
I am trying to code an perl decoder to help me understand the file format. I am testing primary with original files so my routine for reading lbl1 is not working propperly... My assumption is that mkgmap should create files closer to the original ones than to ones created by other compilers because it is possible to hit problem not clearly solved in the other compilers...
[...] If there are points for the cities and LBL1,2,3,4 are filled in the overview map img, menu Find->Find Places has working City tab in MapSource. Maybe overview img participate in the indexing in some
Ah ha, that is interesting. I did recently notice that the trip and waypoint map that came with my GPS had city search even though it does not have the global index file.
The work I've started on the global index will also allow us to create a better overview map too so we could do this then.
Cool! I will target my decoder to dump and analyse mdr files... BR, Anton Todorov
participants (3)
-
Anton Todorov -
Johann Gail -
Steve Ratcliffe