Hi Attached is the first version of the TYP file compiler, using code written by Thomas Lußnig in 2008 to write the TYP file, which has been lying unused in mkgmap since then. It only writes the polygon draw order, so not much use yet, but I expect to be adding the other sections quickly. It reads any valid typ text file, or at least it will read: http://code.google.com/p/mkgmap-style-sheets/source/browse/trunk/typ/world-t... So to use it, first compile a jar as normal. Then run the following command (you can not use the -jar option in this case) java -cp dist/mkgmap.jar uk.me.parabola.mkgmap.typ.TypTextReader <in> <out> <in> defaults to "default.txt" <out> defaults to "OUT.TYP" This method of running it is temporary and may even go away at some point. I will check the code in to trunk, since it is completely separate from anything else in mkgmap. ..Steve
Steve, I haven't tried the compiler yet but I wonder if programms like typ viewer, ati.land.cz and typwiz produce the same txt output from typ files or at least compatible with each other (I'm afraid not). If I'm compiling a txt output generated with the online typ editor ati.land.cz in Typ viewer, I get garbage. Maybe the txt output of Typ viewer (http://code.google.com/p/mkgmap-style-sheets/source/browse/trunk/typ/world-t...) works ok, but will this also work with txt typ files from Typwiz or ati.land.cz? Maybe Nick can comment on this, he is the expert.
Hi Minko
I haven't tried the compiler yet but I wonder if programms like typ viewer, ati.land.cz and typwiz produce the same txt output from typ files or at least compatible with each other (I'm afraid not). If
I'm not too worried about it. To begin with I am going to make the google code[1] default typ style work, since that seems immediately useful. I don't mind adding alternative keywords and dealing with alterative punctuation, but if there are true conflicts, then everyone will just have to work out which one to follow. I've only used ati.land.cz and it is mostly a binary editor. It is able to produce a text file, but it clearly says that it is incomplete and is unlikely to produce the expected results. So I am not going to worry about being compatible with it. I haven't run typwiz yet, tried it under wine, but it didn't run, so will try it later, it looks really good. ..Steve [1] (http://code.google.com/p/mkgmap-style-sheets/source/browse/trunk/typ/world-t...)
Wine will do the trick ;) You may need to run setup.exe first if TYPWiz doesn't run first time. I think the basic issue is : 1) how to create a txt file which incorporates Garmin's recent developments, ie POIs with sizes >32*32 2) how to ensure a TYP file rendering is not hindered by spurious characters I've noticed how sensitive some editors are towards the XPM line & the bitmap that follows - a space in the wrong place or an additional carriagiage return / comment throws them completely . ati does not render some true color pois correctly , ie when number of colors is set to 0; it still assumes you are dealing with a standard,pre 2010 typ file; Typwiz and Typviewer txt files are compatible and both are capable of showing truecolor POIs. -- View this message in context: http://gis.638310.n2.nabble.com/Typ-file-compiler-tp6983717p6988534.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
I've had closer look at the default style and here are a few more observations: The 'code' seems fairly standard and not controversial Polylines: ie 0x11 LineWidth=3 Xpm="0 0 2 0" "1 c #BDCAB4" "2 c #414141" No borderwidth has been declared and presumably it is set to 1 as the line contains 2 colours. Presumably if both linewidths and borderwidth are left out they both are set to 1 Perhaps it is pedantic to always insist on both being mentioned when dealing with non bitmap lines. Roundabout Type=0x0c UseOrientation=N Xpm="32 1 2 1" "! c #000000" " c none" " " This is rendered as 'transparent' ; presumably the other colour was meant as a border? However, as we're dealing with a bitmap line it does seem most unusual for the above to mean: Type=0x0c UseOrientation=N Xpm="32 1 2 1" "! c #000000" " c none" "000000000000000000" " " "000000000000000000" POIs [_point] Type=0x02c SubType=0x06 String1=0x04,park DayXpm="24 24 2 1" Colormode=16 "!? c #FFFFFF" " ? c none" " " " " " " " " etc Again, this point will not be visible, but perhaps that was the initial intention? Finally , how are night versions of POIs going to be represented? I tend to favour NightXpms to follow DayXpms -- View this message in context: http://gis.638310.n2.nabble.com/Typ-file-compiler-tp6983717p6989396.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Nick, About that roundabout: Yes, it is intended as routable transparent line. Typ viewer makes it a bitmap, and a (transparent) colour is specified by default. It is just how this programm works I guess. About the invisible poi: That was intended, because this typ file was made before the mkgmap:area2poi=true rule was introduced.
On 12/11/11 19:00, n Willink wrote:
Wine will do the trick ;) You may need to run setup.exe first if TYPWiz doesn't run first time.
Ah, OK. I ran it and it put up a blue screen without any dialogues, but I hit return a number of times and the dialogue boxes briefly appeared and it completed. Then typwiz ran fine.
I think the basic issue is :
1) how to create a txt file which incorporates Garmin's recent developments, ie POIs with sizes>32*32
OK I'm beginning to see where the problems are now that I have completed the first stage of the compiler. I'll take a look at the format that typwiz produces for those extensions.
2) how to ensure a TYP file rendering is not hindered by spurious characters
I've noticed how sensitive some editors are towards the XPM line& the bitmap that follows - a space in the wrong place or an additional carriagiage return / comment throws them completely .
The way its written is almost completely insensitive to new lines and spaces. In fact I had the opposite problem, in an XPM definition a space at the beginning is significant. ..Steve
participants (3)
-
Minko -
n Willink -
Steve Ratcliffe