a few more typ compiler problems
Great! True color pois are now rendered correctly except for colormode=32 However,I've come across a few more blemishes. (http://www.pinns.co.uk/osm/txt2typ.zip) 1) topo1.txt : all 'place' pois get type number 0x0000 2) topo2.txt : java issues http://www.pinns.co.uk/osm/txt2typ.zip the above errors occur with other txt files as well 3) font: normal is still not accepted, it seems. -- View this message in context: http://gis.638310.n2.nabble.com/a-few-more-typ-compiler-problems-tp7132907p7... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Nick
Great! True color pois are now rendered correctly except for colormode=32
Good, I haven't implemented colour modes 16 and 32 yet for true colour images, but it is something that I will implement soon.
However,I've come across a few more blemishes.
(http://www.pinns.co.uk/osm/txt2typ.zip)
1) topo1.txt : all 'place' pois get type number 0x0000
OK thanks, only using both Type and SubType is working at the moment, but is easily fixed and I have a solution ready to commit.
2) topo2.txt : java issues
I will increase the space available for the labels to deal with this. Is there any limit on the number of languages that can be used at once? I've only ever seen at most 4 in use.
3) font: normal is still not accepted, it seems.
I've not added that yet, but now I am back home and will get all these things tidied up over the next few days. ..Steve
"I will increase the space available for the labels to deal with this. Is there any limit on the number of languages that can be used at once? I've only ever seen at most 4 in use. " I think the issue is perhaps not the number of languages but the length of the text & language code stream. I have come across streams with sizes of 2k - to me its quite clumsy how you need to know the length of each poi data block to determine whether the text length requires 1 or 2 bytes. In reality though I think most of us would only use a max of 2 to 3 languages. Will continue testing latest version. Great work! ..Nick -- View this message in context: http://gis.638310.n2.nabble.com/a-few-more-typ-compiler-problems-tp7132907p7... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Nick
I think the issue is perhaps not the number of languages but the length of the text& language code stream.
Ah, that was something I didn't know about - how to represent a length greater than 127. Its just the same kind of variable length integer as used in mdr17 so it should work now. I think I've now covered all the small bugs: - types of the form 0xYYZZ now work - strings totally more than 127 bytes - Normal now accepted as well as NormalFont - font Default now translates to 0 rather than 3. Still have mode 16 and 32 for true colour images to do. ..Steve
Hi Steve Brilliant to hear you've addressed those minor issues. Interesting what you were saying about mdr17; have not looked at this subfile yet but you may be right: 2 byte lengths are : (length of txt -5)*2) / (2*2) no idea if it allows for 3 byte lengths... btw you may like to know that some old topos include pois with colour set to zero. These confusingly contain no colour or bitmap data and hence do not indicate true color. I can't imagine anyone today using such pois. ..Nick -- View this message in context: http://gis.638310.n2.nabble.com/a-few-more-typ-compiler-problems-tp7132907p7... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 29/12/11 22:31, n Willink wrote:
2 byte lengths are : (length of txt -5)*2) / (2*2) no idea if it allows for 3 byte lengths...
The way I think about it is that the binary representation of the integer ends in a 1 followed none or more number of zeros. The total bit length of this suffix is the number of bytes in the integer. You then remove the suffix by shifting right by the suffix length (or equivalently divide by 2 that number of times). 1 - 1 byte 10 - 2 bytes 100 - 3 bytes I didn't bother dealing with the 3 byte case in the typ file. If anyone really needs more than 64k bytes of strings I am sure they will let me know! ..Steve
Another typ compiler problem of a different kind: If --output-dir is active, and a txt file is used for the input for the typ file generation, there is a problem in the nsis file. With a typ file as input, it is working as expected: !define TYPNAME "typfile.typ" With a txt file nsis creates this: !define TYPNAME "output-dir/typfile.typ" Is this intended? If I install the maps, the typ file is not found. It will look in c:\garmin\maps\osm_map\07-01-2011 (if output-dir is the current date, instead of c:\garmin\maps\osm_map\)
On 07/01/12 12:04, Minko wrote:
If --output-dir is active, and a txt file is used for the input for the typ file generation, there is a problem in the nsis file.
With a typ file as input, it is working as expected:
!define TYPNAME "typfile.typ"
With a txt file nsis creates this:
!define TYPNAME "output-dir/typfile.typ"
Is this intended?
No it should not include the output-dir. I will fix that. ..Steve
Thanks for committing, Steve. Forgot to mention another issue, that is when I use --output-dir and a (.typ) typ file, the typ file isn't copied to the output-dir. Neither if I put it at the end in the mkgmap java command, nor in the args file.
On 08/01/12 21:48, Minko wrote:
Thanks for committing, Steve.
Forgot to mention another issue, that is when I use --output-dir and a (.typ) typ file, the typ file isn't copied to the output-dir. Neither if I put it at the end in the mkgmap java command, nor in the args file.
Yes I suppose it should be copied really. Might have to think about that one for a bit. ..Steve
participants (3)
-
Minko -
n Willink -
Steve Ratcliffe