In general I now got it fully working - the problem is if those merged
tiles are split - and not split in "pairs" but say from two tiles that
failed - which are not adjacent - 3 tiles are created (or 5) there
sometimes will be a tile spanning another tile. This works as far as I can
see in Basecamp/MapInstall/Mapsource - but gives strange impression when
selecting the tiles in MapInstall/Mapsource.
Have not yet tested it on device.
So if there is no possibility for splitter to implement a multiple single
input tile mode - I will have to resort to writing a big for loop calling
splitter separately for each crashed tile on mkgmap.jar processing. It
often can be prevented by using exactly 50% maxnodes size on resplit - but
that is not reliable of course. Basically for each tile that is 0 byte, you
need to split the original o5m, remove the mention to the input-file from
the template.args file, after each run check for a new highest mapid (or if
splitting with 50% maxnodes just add 3), always delete all 0byte files -
and after all tiles are split run mkgmap.jar again (either on the existing
.img files plus the new templates.args file (from joining all the
templates.args now newly created - also required quite a bit of logic).
It's scriptable - but really requires a lot of work. Would be great if
splitter.jar has a multiple tile input method (even more if it could
multithread that one as usual). If not the multithreading of course can be
achieved by piping each of these broken tiles into a separate process for
splitting.
On Tue, 31 Aug 2021 at 12:23, Felix Hartmann
wrote:
> That step is very easy.
>
> You feed %FID% (if you use fid for first 4 numbers of mapid) and the new
> template.args to mkgmap.jar. No need to recreate the .img files that are
> okay. The broken ones - all 0byte ones - just delete them. If you wanna run
> mkgmap again on the same o5m input files - you join the template.args file
> from both runs - I always replace mapname with #notused so the
> template.args only contains description and the actual input file. It
> throws a warning that input files are missing - but that is allright. Of
> course you need to add in your script to delete those input files that were
> resplit.
>
> I don't know what your "app" does - but the process is pretty simple. As
> long as splitter can handle the several input files with --keep-complete
> (and just runs keep-complete on each input file but not on the totality of
> input files, plus does not try to join data from two files). And yes as
> said - if you want to run splitter on each input file separately, that
> creates loads of work - I don't know how to script that efficiently. Oh
> yeah - and your script needs to read the highest number of the maps created
> - add 1, and run mkgmap again with that number. But yeah - scripting this
> takes some time. But it is understandable that mkgmap cannot call
> splitter.jar on it's ownThe main thing in this is getting to run
> splitter on several input files with keep-complete valid for each tile on
> it's own.
> But yeah I think osmconvert 100.o5m 11.o5m 100010.o5m
> -o=inputfile.o5m
> and then calling mkgmap with the higher mapid, and *already_created.img
> inputfile.o5m would suffice. So far I cannot see problems (as long as using
> keep-complete=true) - you can even do a third pass. You cannot do a third
> pass if you use keep-complete=false overlap=2000
> because the overlap would create a huge mess (or better objects ending up
> twice in your map)
>
> On Tue, 31 Aug 2021 at 11:33, Eric Internet wrote:
>
>> Also do not understand and on vacation now, so my options for
>> understanding are very limited.
>>
>> But fwiw...
>>
>> Mkgmap should read files collection from contents files. One o5m file
>> missing or 1 file extra (having different FID) is a show stopper. (Missing
>> files is not tested, assumption only).
>>
>> I create 2-6 different maps each overnight from same dataset by simply:
>> - Rename all o5m files by FID
>> - Rename Reference in two content files by filename (changed by FID).
>> This procedure takes seconds to run.
>>
>> All scripts (power management, splitter, OsmConvert, mkgmap, NSI) are
>> executed by shell.run from within a "wrapper application".
>> VB exe is: flexible, configurable, unlimited procedures and language
>> elements.
>>
>> App UI checkboxes will select which datasets to download.
>> App UI checkboxes will select which maps to be created.
>> UI settings are saved in iNI file for Unattended execution.
>> App will decide which datasets need to be merged by OsmConvert.
>> App will check preconditions.
>> App will run preprocess procedures (f.i. Rename by FID).
>> App will wait for recent "latest" dataset.
>> App will retry a failed download for n-times.
>> App will decide what to do if a dataset is missing or outdated.
>> App will verify each step to be successful (or not).
>> App will install correctly created maps (read log files) into BaseCamp.
>> Installer exe
