Using multiple TYP files
I'm having trouble combining IMG files with different product and family IDs into a single gmapsupp.img. I can create single-family images with no problem, but trying to create a multiple-family image thusly: /-------- | $(MKGMAP) --gmapsupp \ | --family-id=1672 --product-id=1672 1672*.img 1672.TYP \ | --family-id=6324 --product-id=6324 6324*.img 6324.TYP \-------- results in all the image files getting the 6324 IDs, and so the 1672* files appear in the wrong style. It also means that I can't selectively show or hide the two families. How best to combine the two?
2010/3/22 Toby Speight <T.M.Speight.90@cantab.net>:
/-------- | $(MKGMAP) --gmapsupp \ | --family-id=1672 --product-id=1672 1672*.img 1672.TYP \ | --family-id=6324 --product-id=6324 6324*.img 6324.TYP \--------
How best to combine the two?
Do it sequentially. $(MKGMAP) --gmapsupp --family-id=1672 --product-id=1672 1672*.img 1672.TYP mv gmapsupp.img gmapsupp1.img $(MKGMAP) --gmapsupp --family-id=6324 --product-id=6324 6324*.img 6324.TYP mv gmapsupp.img gmapsupp2.img $(MKGMAP) --gmapsupp gmapsupp1.img gmapsupp2.img Then you get a gmapsupp.img that contains what you want.
0> In article <61af4ce51003220852q2e3efcccta68324526a7710f@mail.gmail.com>, 0> Christoph Wagner <URL:mailto:freemaps.osm@googlemail.com> ("CW") wrote: CW> Do it sequentially. CW> CW> $(MKGMAP) --gmapsupp --family-id=1672 --product-id=1672 1672*.img 1672.TYP CW> mv gmapsupp.img gmapsupp1.img CW> $(MKGMAP) --gmapsupp --family-id=6324 --product-id=6324 6324*.img 6324.TYP CW> mv gmapsupp.img gmapsupp2.img CW> $(MKGMAP) --gmapsupp gmapsupp1.img gmapsupp2.img CW> CW> Then you get a gmapsupp.img that contains what you want. Ah, I didn't realise you could use a gmapsupp.img as input. Your recipe above works like a dream - many thanks! :-)
CW> $(MKGMAP) --gmapsupp gmapsupp1.img gmapsupp2.img CW> CW> Then you get a gmapsupp.img that contains what you want.
Ah, I didn't realise you could use a gmapsupp.img as input. Your recipe above works like a dream - many thanks! :-)
You can although it was only fairly recently that it was implemented. I'm not sure why your original command is not working, I've just tried it and it works for me. I'd need more information to look into it further. ..Steve
0> In article <87mxy0e691.fsf@balti.ashgrove>, 0> Toby Speight <URL:mailto:T.M.Speight.90@cantab.net> ("Toby") wrote: Toby> /-------- Toby> | $(MKGMAP) --gmapsupp \ Toby> | --family-id=1672 --product-id=1672 1672*.img 1672.TYP \ Toby> | --family-id=6324 --product-id=6324 6324*.img 6324.TYP Toby> \-------- Steve> That is supposed to work just as you have it. Steve> Steve> I thought there was even a test for it! Steve> I'll investigate. It's a while since I looked at the option parsing code, but IIRC, all the non-file arguments are processed before starting to read any of the files, contrary to the documentation. I could be wrong, though.
On 03/22/2010 05:36 PM, Toby Speight wrote:
It's a while since I looked at the option parsing code, but IIRC, all the non-file arguments are processed before starting to read any of the files, contrary to the documentation. I could be wrong, though.
Creating a gmapsupp.img with several family-IDs does work for me when I use an options file with the "-c" option. Didn't try on the command line, though.
0> In article <4BA7D179.7030108@kleineisel.de>, 0> Ralf Kleineisel <URL:mailto:ralf@kleineisel.de> ("Ralf") wrote: Ralf> Creating a gmapsupp.img with several family-IDs does work for me Ralf> when I use an options file with the "-c" option. That's a bit more difficult for me - I'd have to generate it on the fly, as I don't know how many tiles the splitter is going to throw out. Unless there's a way around that?
Toby Speight schrieb am 23.03.2010 11:03:
That's a bit more difficult for me - I'd have to generate it on the fly, as I don't know how many tiles the splitter is going to throw out. Unless there's a way around that?
If you are always splitting the same areas, you can use an area list as parameter for splitter for defining the cuttings (parameter --split-file). I think splitter always outputs such a split file. So I have done once the splitting without the split-file parameter to get such a file, and afterwards I am using always this as input parameter for the following cuttings, so that I always get the same tiles. Gruss Torsten
Torsten Leistikow (de_muur@gmx.de) wrote:
Toby Speight schrieb am 23.03.2010 11:03:
That's a bit more difficult for me - I'd have to generate it on the fly, as I don't know how many tiles the splitter is going to throw out. Unless there's a way around that?
If you are always splitting the same areas, you can use an area list as parameter for splitter for defining the cuttings (parameter --split-file).
I think splitter always outputs such a split file. So I have done once the splitting without the split-file parameter to get such a file, and afterwards I am using always this as input parameter for the following cuttings, so that I always get the same tiles.
Gruss Torsten This also shortens the splitter processing time as it already knows what tiles to create.
-- Charlie
Torsten Leistikow escribió:
Toby Speight schrieb am 23.03.2010 11:03:
That's a bit more difficult for me - I'd have to generate it on the fly, as I don't know how many tiles the splitter is going to throw out. Unless there's a way around that?
If you are always splitting the same areas, you can use an area list as parameter for splitter for defining the cuttings (parameter --split-file).
I think splitter always outputs such a split file. So I have done once the splitting without the split-file parameter to get such a file, and afterwards I am using always this as input parameter for the following cuttings, so that I always get the same tiles.
In addition to the above, you can use the template.args file generated by splitter as a base for your -c file.
0> In article <4BA8D823.6090605@gmx.de>, 0> Torsten Leistikow <URL:mailto:de_muur@gmx.de> ("Torsten") wrote: Torsten> Toby Speight schrieb am 23.03.2010 11:03:
That's a bit more difficult for me - I'd have to generate it on the fly, as I don't know how many tiles the splitter is going to throw out. Unless there's a way around that?
Torsten> If you are always splitting the same areas, you can use an Torsten> area list as parameter for splitter for defining the cuttings Torsten> (parameter --split-file). That's true - until the area density grows too big and it needs resetting. It could be a pain maintaining all the template rules (I run splitter probably a dozen times, given the number of input files).
On 03/23/2010 11:03 AM, Toby Speight wrote:
That's a bit more difficult for me - I'd have to generate it on the fly, as I don't know how many tiles the splitter is going to throw out. Unless there's a way around that?
With a bit of (shell-/perl-/whatever-)-scripting it isn't hard to include the template generated by the splitter into a general options template. With an options file you can use the geonames-option better, too, IMHO.
participants (7)
-
Carlos Dávila -
charlie＠cferrero.net -
Christoph Wagner -
Ralf Kleineisel -
Steve Ratcliffe -
Toby Speight -
Torsten Leistikow