Hi I'd like to merge the typ branch back soon, since the changes that affect mkgmap have been done and are small. I've written a page describing the syntax of the language accepted by the compiler to accompany it: http://wiki.openstreetmap.org/wiki/Mkgmap/help/typ_compile ..Steve
Am 28.11.2011 15:10, schrieb Steve Ratcliffe:
I'd like to merge the typ branch back soon, since the changes that affect mkgmap have been done and are small.
I've written a page describing the syntax of the language accepted by the compiler to accompany it:
Hi, thank's for the docs. Is it compatible with the txt output generated by the Typviewer.exe program? http://opheliat.free.fr/michel40/TYPViewer3.5/ Chris
Hi
thank's for the docs. Is it compatible with the txt output generated by the Typviewer.exe program? http://opheliat.free.fr/michel40/TYPViewer3.5/
Yes. You can usually read a typ file into typviewer, write it in .txt and compile it with the mkgmap typ compiler and get the same typ file. Of course there may be bugs in either program. With the mapnik.typ file, typviewer converts one of the lines with a border width of 1 to having no border width in its .txt output. ..Steve
Hi
I'd like to merge the typ branch back soon, since the changes that affect mkgmap have been done and are small.
I've written a page describing the syntax of the language accepted by the compiler to accompany it:
Are the values for the language codes documented somewhere? I guess the list is not too long; maybe it could be included on this page? Also, how can the code page in which the TYP-file is expressed be specified? Can we use UTF-8 for example? Colin
Hi
Are the values for the language codes documented somewhere? I guess the list is not too long; maybe it could be included on this page?
Yes, it would be a good idea to include a list on the page or referenced from there, I shall do that.
Also, how can the code page in which the TYP-file is expressed be specified? Can we use UTF-8 for example?
Ah this is a good point that I meant to mention. The mkgmap compiler prefers them to be written in UTF-8, so you should write them that way if you have the choice. However many existing ones are not, so if reading them in utf-8 fails, I then try to read them in the code page that is declared in the file. ..Steve
Hi, I'm back from a longer holiday and haven't read every mail. So maybe my comments could already be discussed. First: It works nearly perfect! My problem is, that the generated typ-file will not written to the given output dictionary. That would be a very useful thing. The other thing is the name of the typ-file. Would it be possible to use the name of the txt-file? Henning
On 07/12/11 15:54, Henning Scholland wrote:
Hi, I'm back from a longer holiday and haven't read every mail. So maybe my comments could already be discussed. First: It works nearly perfect!
Great!
My problem is, that the generated typ-file will not written to the given output dictionary. That would be a very useful thing.
Yes, good point it should do that.
The other thing is the name of the typ-file. Would it be possible to use the name of the txt-file?
There was some discussion about that, but I think that you have the right answer. That's how it should be unless anyone can give a reason why not. ..Steve
I agree to use the name of the txt file, so everybody can easily rename the txt file in order to get the typ file as family-id.typ, family-name.typ, overview-mapname.typ etc Steve wrote:
The other thing is the name of the typ-file. Would it be possible to use the name of the txt-file?
There was some discussion about that, but I think that you have the right answer. That's how it should be unless anyone can give a reason why not.
Typ compiler (mkgmap-r2136) still has problems with the draw order of these (background) polygons: 0x10100 and 0x10101 input txt file [_drawOrder] Type=0x032,1 Type=0x10100,2 Type=0x10101,2 Type=0x001,3 Type=0x002,3 etc output typ file [_drawOrder] Type=0x032,1 Type=0x10101,2 Type=0x001,3 Type=0x002,3 etc I've tried to replace 0x10101 type with 0x10200 instead (maybe subtypes are not allowed?) of but this seems not to work either: input txt file [_drawOrder] Type=0x032,1 Type=0x10100,2 Type=0x10200,2 Type=0x001,3 Type=0x002,3 etc Output: [_drawOrder] Type=0x032,1 Type=0x001,2 Type=0x002,2 Type=0x001,3 Type=0x002,3 etc btw I tried it also with mkgmap-typ-r2129 from the branch but then the typviewer crashes when trying to read the typ file.
On 08/12/11 14:39, Minko wrote:
Typ compiler (mkgmap-r2136) still has problems with the draw order of these (background) polygons: 0x10100 and 0x10101
At the time I wrote this I believed that you could not have a subtype of 0 for an extended type in the typ format, but I now think that was wrong. So patch attached which I will commit.
btw I tried it also with mkgmap-typ-r2129 from the branch but then the typviewer crashes when trying to read the typ file.
That branch is finished now. I've made one change since to fix bad output which is probably the problem you saw. ..Steve
steve if you mean 0x10000 etc then it would be 00 , 01, 00, 00, 00 in the draworder block ie &h100 mod 256, 2^0, , , , -- View this message in context: http://gis.638310.n2.nabble.com/TYP-compiler-tp7038853p7075156.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (6)
-
Chris66 -
Colin Smale -
Henning Scholland -
Minko -
n Willink -
Steve Ratcliffe