PS: as a "cheap" workaround you can add a column type "size difference" and make it sortable
threshold for size difference
@Bob: RTFM Quote from MOBAC format documentation: Atlases created after another are merged into one Database named [AtlasName] atlas.sqlitedb which is located in the atlas output directory.
@Laurent: you simply use the same DB name in the profile (DB type Big Planet e.g., will use simplest possible sqlitedb data model) and execute them one after the other - even parallel processing is doable, as long as the write phases into the DB do not overlap. (Patience is more peace of mind here :-)) Once you have such a DB file, you can use it as a local source, which has NO limits For Bob this would mean: respecting the download limits - for good reasons as Robert advised - and execute those...
@Laurent: you simply use the same DB name in the profile (DB type Big Planet e.g., will use simplest possible sqlitedb data model) and execute them one after the other - even parallel processing is doable, as long as the write phases into the DB do not overlap. (Patience is more peace of mind here :-)) Once you have such a DB file, you can use it as a local source, which has NO limits For Bob this would mean: respecting the download limits - for good reasons as Robert advised - and execute those...
I am not relying on tilestore for my world maps. But rather use sqlitedb. Such DBs can accumulate any number of tiles. No need for merging, just feed this DB via multiple profiles. Then you have a local source for which no limits apply. Without a single line of code, nor change to MOBAC. Cheers Michael
I am generating maps with 1m+ with current MOBAC. So there must be subtle difference in settings and configurations of profiles and sources.
PS: in 2.3.1 there seems to be no boundary information in the meta data if there are multiple maps on the same ZL. I would consider the UNION (i.e. no intersection at all, very simple change) as described earlier for a future release - or go just like 2.3.1 in this regard.