Hi The TYP compiler is now integrated into mkgmap on the typ branch. You should be able to supply a .txt file on the command line and it will be compiled along with any other files. If the gmapsupp option is given then the compiled TYP will be copied into the gmapsupp as you would expect. Likewise the compiled TYP name will be in the nsis file if that option is given. If family-id, product-id or code-page options are given, then they override the values given in the input .txt file, so that the TYP will work with rest of the map. So it should just work, I'm sure you will let me know if it doesn't... ..Steve
Hi Steve, Thanks for integrating the typ/txt file into mkgmap. It seems to work pretty well, except for a few remarks: The header size This is not specified when I export my typ file to txt with typ viewer so it is set to short (old format). I noticed this give problems with extended polygon types like this one [_polygon] Type=0x10100 String1=0x04,area String2=0x03,gebied String3=0x02,Gebiet ExtendedLabels=Y FontStyle=NoLabel (invisible) CustomColor=No Xpm="0 0 2 0" "1 c #D8F7BA" "2 c #FFFFD5" [end] In the draw order section, type 0x10100 does not get a draw priority (0x10101 is a different polygon background for another map) [_drawOrder] Type=0x032,1 Type=0x10101,2 Type=0x001,3 Type=0x002,3 etc I noticed the same when I import this typ file into ati.land.cz Draw orders of 0x100 or higher are not read very well and ati.land.cz makes a mess with those polygons. ati.land.cz also complains that the header is in old format. This bug doesn't appear if I set the header in the typ file to NT (new) or NT2 Unfortunately I can't save this information with typ viewer, the header is always set to short (old) format when I save it to txt. Maybe it is better not to use those extended polygons at all? Or is there a way to get this header info into the text file? The TYP file name Another issue is that mkgmap compiles my typfile.txt into MKG(FID).TYP. Is it possible to specify the name of the typ file that is created? For instance If I put this line in the args file mapname: 10010.typ input-file: typfile.txt
On 16/11/11 10:20, Minko wrote:
Hi Steve, Thanks for integrating the typ/txt file into mkgmap. It seems to work pretty well, except for a few remarks:
The header size
This is not specified when I export my typ file to txt with typ viewer so it is set to short (old format). I noticed this give problems with extended polygon types like this one
[_polygon] Type=0x10100 String1=0x04,area String2=0x03,gebied String3=0x02,Gebiet ExtendedLabels=Y FontStyle=NoLabel (invisible) CustomColor=No Xpm="0 0 2 0" "1 c #D8F7BA" "2 c #FFFFD5" [end]
In the draw order section, type 0x10100 does not get a draw priority (0x10101 is a different polygon background for another map)
[_drawOrder] Type=0x032,1 Type=0x10101,2 Type=0x001,3 Type=0x002,3 etc
I noticed the same when I import this typ file into ati.land.cz Draw orders of 0x100 or higher are not read very well and ati.land.cz makes a mess with those polygons. ati.land.cz also complains that the header is in old format.
This bug doesn't appear if I set the header in the typ file to NT (new) or NT2 Unfortunately I can't save this information with typ viewer, the header is always set to short (old) format when I save it to txt. Maybe it is better not to use those extended polygons at all? Or is there a way to get this header info into the text file?
The TYP file name
Another issue is that mkgmap compiles my typfile.txt into MKG(FID).TYP. Is it possible to specify the name of the typ file that is created?
For instance If I put this line in the args file
mapname: 10010.typ input-file: typfile.txt
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Minko [Sorry about previous blank email!]
The header size
This is not specified when I export my typ file to txt with typ viewer so it is set to short (old format). I noticed this give problems with extended polygon types like this one
Right, I was working with the minimum header size while testing with the mapnik.txt file, but I've now gone back to the larger size - oh yes probably not checked in yet - will do so soon. My local copy seems to work with the cases you mention.
Another issue is that mkgmap compiles my typfile.txt into MKG(FID).TYP. Is it possible to specify the name of the typ file that is created?
That was a bad choice I agree. How about using --overview-mapname so it would be named the same as all the other extra files by default? ie osmmap.typ by default? ..Steve
On Wed, Nov 16, 2011 at 02:29:54PM +0000, Steve Ratcliffe wrote:
Another issue is that mkgmap compiles my typfile.txt into MKG(FID).TYP. Is it possible to specify the name of the typ file that is created?
That was a bad choice I agree. How about using --overview-mapname so it would be named the same as all the other extra files by default? ie osmmap.typ by default?
What if you want to have multiple map layers in a single gmapsupp.img (for old devices that do not support .img file selection)? Then I guess you could want to have up to one TYP file per family-id. Or would you have multiple overview maps (one per family-id) anyway? Marko
What if you want to have multiple map layers in a single gmapsupp.img (for old devices that do not support .img file selection)? Then I guess you could want to have up to one TYP file per family-id.
Or would you have multiple overview maps (one per family-id) anyway?
I think I would build separately, and then combine in a second step. However, everything is possible: overview-mapname: mapset1 family-id: 1001 input-file: first-typ.txt # will be called mapset1.typ overview-mapname: mapset2 family-id: 1002 input-file: second-typ.txt # will be called mapset2.typ # Any tdb file etc will be called osmmap overview-mapname: osmmap ..Steve
For my cyclemaps I use {Family-ID}.typ (10010 and 20010.typ) so it would be nice if that would be possible to use this too. --------- Steve wrote: I think I would build separately, and then combine in a second step. However, everything is possible: overview-mapname: mapset1 family-id: 1001 input-file: first-typ.txt # will be called mapset1.typ overview-mapname: mapset2 family-id: 1002 input-file: second-typ.txt # will be called mapset2.typ # Any tdb file etc will be called osmmap overview-mapname: osmmap
participants (3)
-
Marko Mäkelä -
Minko -
Steve Ratcliffe