<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hi Felix,<br><br>thanks for the info regarding tile limits. I think there is not much we can<br>do in the program(s) to avoid that.<br><br>Reg. splitter called from mkgmap:<br>I think calling splitter from mkgmap is possible, but not simple.<br>1) We have to make sure that splitter.jar is available.<br>2) I can't simply call the Main routine of splitter, because<br>the code contains many calls to System.exit() which would <br>also end mkgmap. In other words, I have to call it creating a new JVM.<br>3) Reg. parameters for splitter: This is quite complex.<br>We can't simply use the parameters of the initial splitter call,<br>because e.g. no-trim , mapid, polygon-file,etc. have to be changed<br>to make sure that the result still fits into the map.<br>4) Next problem: <br>splitter output files like areas.list, *.kml, template.args<br>What should happen with them ?<br><br>In short:<br>I fear this change, it has a lot of potential to mess up things <br>and make the two programs more OS dependend :-(<br><br>I still think the better alternative would be to collect some kind of<br>statistic in mkgmap which is usable for splitter to weight <br>the number of nodes in a given area.<br>The process would then be:<br><br>if no feedback file exits, create an empty one<br>repeat<br> - execute splitter with input file and feedback from mkgmap<br> - execute mkgmap (which creates a new feedback file)<br>until mkgmap finishes with rc 0<br><br>This is also not simple, as I don't know how to calculate the feedback.<br>A first simple approach would be this:<br>bbox + size of img file <br><br>In the meantime I will try to find a better algo in splitter to avoid <br>very small output files. The current algo is happy if the <br>no tile has less then 1/3 of the --max-nodes value,<br>if that can't be done, it accepts also smaller values.<br><br>Gerd<br><br><div>> Date: Mon, 5 May 2014 13:58:07 +0200<br>> From: extremecarver@gmail.com<br>> To: mkgmap-dev@lists.mkgmap.org.uk<br>> Subject: Re: [mkgmap-dev] mkgmap ToDo list<br>> <br>> okay - I'll give it a try tomorrow (not much more time today).<br>> As for mkgmap calling splitter - I think the important bit is to hand <br>> over mkgmap the splitter "command" used. Maybe in a file that splitter <br>> writes after splitting?<br>> I don't think it's important that the splitted files are in perfect <br>> numeric order - but it would be great if mkgmap could keep numeric order <br>> without missing numbers..<br>> <br>> <br>> About the tile limit:<br>> That's a tricky one - because there is no warning. The gps units simply <br>> stop reading in further map tiles after 2025 on most units, and 4000 on <br>> Oregon and some other modern units.<br>> So people wonder why the map doesn't show up even though it's activated <br>> - and the reason is then to be found in the tile limit...<br>> <br>> I'm not sure if only map display and routing is affected, or also POI <br>> search. The problematic thing is - it's at least for the user nearly <br>> impossible to know which tiles were read in, and which not (of course <br>> it's not random - but hard to find out the order that the device uses, <br>> so it's most likely many maps showing correctly, one partly, some not at <br>> all).<br>> <br>> <br>> It would be great if tiles were a bit bigger - but I would not use the <br>> mkgmap interaction to completly foregoe setting max-nodes or trying to <br>> get all maptiles 9-18MB in size. It would just be great if those very <br>> small tiles (1 to say 4MB for me) would not be so common anymore as like <br>> now where I need to work with very low max-nodes values.<br>> On 05.05.2014 13:49, GerdP wrote:<br>> > Hi Felix,<br>> ><br>> > I did not try with Europe, only with Finland, but I see no reason why it<br>> > should not work.<br>> > I'll see what I can do regarding the automatic call of splitter from mkgmap.<br>> ><br>> > Gerd<br>> ><br>> ><br>> > Felix Hartmann-2 wrote<br>> >> Well - I suppose that is only for continuing to split. Not like saying I<br>> >> want to split europe and --num-tiles=600 or?<br>> >> Anyhow that's very good in case mkgmap would pass back osm.pbf files to<br>> >> splitter that failed compiling. Because then it could pass forward -<br>> >> "split into 2 tiles" :-)<br>> >><br>> >> Or better -there is no real change in the splitting algo behind I assume<br>> >> on counting max-nodes or whatever else..<br>> >> On 05.05.2014 09:28, Gerd Petermann wrote:<br>> >>> Hi Lambertus,<br>> >>><br>> >>> attached is a patch that implements the new option:<br>> >>> --num-tiles A target value that is used when no split-file is<br>> >>> given.<br>> >>> Splitting is done so that the given number of tiles is<br>> >>> produced. The max-nodes value is ignored if this<br>> >>> option is<br>> >>> given.<br>> >>> A compiled binary is here:<br>> >>><br>> >>> |http://files.mkgmap.org.uk/download/206/splitter.jar<br>> >>><br>> >>> Please let me know if it works as expected.<br>> >>><br>> >>> Gerd<br>> >>> |<br>> >>> ------------------------------------------------------------------------<br>> >>> Date: Sun, 4 May 2014 22:20:20 +0200<br>> >>> From:<br>> >> osm@<br>> >>> To:<br>> >> mkgmap-dev@.org<br>> >>> Subject: Re: [mkgmap-dev] mkgmap ToDo list<br>> >>><br>> >>> Great, many thanks. I'm currently trying to create as large as<br>> >>> (automatically) possible contour tiles and a lot of time is put in<br>> >>> subsplitting a tile again and again until two subtiles appear. This<br>> >>> new option would save much time.<br>> >>><br>> >>> On 05/04/2014 10:13 PM, Gerd Petermann wrote:<br>> >>><br>> >>> Hi Lambertus,<br>> >>><br>> >>> yes, I want to code that tomorrow. I prefer to make it "give me n<br>> >>> tiles", but if that turns out to be<br>> >>> difficult I try the simple version. I can think of scenarios where<br>> >>> it is not possible to create exactly<br>> >>> n tiles.<br>> >>><br>> >>> Gerd<br>> >>><br>> >>> <br>> >>> ------------------------------------------------------------------------<br>> >>> Date: Sun, 4 May 2014 22:08:32 +0200<br>> >>> From:<br>> >> osm@<br>> >> &lt;mailto:<br>> >> osm@<br>> >> &gt;<br>> >>> To:<br>> >> mkgmap-dev@.org<br>> >>> &lt;mailto:<br>> >> mkgmap-dev@.org<br>> >> &gt;<br>> >>> Subject: Re: [mkgmap-dev] mkgmap ToDo list<br>> >>><br>> >>> Is the 'just give me two tiles' option for splitter on the to-do<br>> >>> list? I'd really appreciate such a function.<br>> >>><br>> >>> On 05/04/2014 09:36 PM, Gerd Petermann wrote:<br>> >>><br>> >>> Hi Felix,<br>> >>><br>> >>> > would using the precomp-sea parameter for splitter improve<br>> >>> results? It's not that tiles with loads of sea actually failed.<br>> >>><br>> >>> good question. I've coded that parameter in splitter before we<br>> >>> did some important changes in mkgmap.<br>> >>> I think it is needed when you use a polygon file in<br>> >>> combination with an imput file that doesn't cover the polygon.<br>> >>> If the polygon covers a costline with a lot of islands, but<br>> >>> the input file doesn't contain the data,<br>> >>> splitter might create large tiles covering these "empty"<br>> >>> areas. Later, in mkgmap, the empty<br>> >>> areas are filled with the precompiled-sea data, and that can<br>> >>> cause too large files.<br>> >>><br>> >>> BTW: The quick hack turned out to be useless. It worked better<br>> >>> in some areas and worse in others.<br>> >>> I'll look again at this later next week.<br>> >>><br>> >>> Gerd<br>> >>><br>> >>><br>> >>><br>> >>> <br>> >>> ------------------------------------------------------------------------<br>> >>> Date: Sun, 4 May 2014 21:21:59 +0200<br>> >>> From:<br>> >> extremecarver@<br>> >> &lt;mailto:<br>> >> extremecarver@<br>> >> &gt;<br>> >>> To:<br>> >> mkgmap-dev@.org<br>> >>> &lt;mailto:<br>> >> mkgmap-dev@.org<br>> >> &gt;<br>> >>> Subject: Re: [mkgmap-dev] mkgmap ToDo list<br>> >>><br>> >>> No - I use splitter like this - with maxnodes depending on<br>> >>> area - I usually just reduced it after failures to compile a<br>> >>> tile.:<br>> >>> java -Xms4000m -Xmx10400m -jar c:\openmtbmap\splitter.jar<br>> >>> --max-nodes=%maxnodes% --max-threads=8 --output=pbf<br>> >>> --keep-complete --max-areas=1524 --geonames-file=cities5000<br>> >>> --description=%country% --mapid=%FID%0000<br>> >>> c:\OpenMTBMap\osmpbf_geofabrik\%country%-latest.osm.pbf<br>> >>> would using the precomp-sea parameter for splitter improve<br>> >>> results? It's not that tiles with loads of sea actually failed.<br>> >>><br>> >>> On 03.05.2014 09:00, Gerd Petermann wrote:<br>> >>><br>> >>> Hi all,<br>> >>><br>> >>> I've coded a quick hack which seems to improve the ratios.<br>> >>> On the other hand, I don't see these large differences<br>> >>> between<br>> >>> smallest and largest img file.<br>> >>> What part of the world should I try?<br>> >>> Do you use the precomp-sea parameter in splitter?<br>> >>><br>> >>> Gerd<br>> >>><br>> >>> <br>> >>> ------------------------------------------------------------------------<br>> >>> Date: Wed, 30 Apr 2014 14:59:32 +0200<br>> >>> From:<br>> >> extremecarver@<br>> >> &lt;mailto:<br>> >> extremecarver@<br>> >> &gt;<br>> >>> To:<br>> >> mkgmap-dev@.org<br>> >>> &lt;mailto:<br>> >> mkgmap-dev@.org<br>> >> &gt;<br>> >>> Subject: Re: [mkgmap-dev] mkgmap ToDo list<br>> >>><br>> >>> if that doesn't seriously (more than 30-40%) slow down the<br>> >>> splitter, I assume it would be much better...<br>> >>> On 30.04.2014 14:06, Gerd Petermann wrote:<br>> >>><br>> >>> Hi,<br>> >>><br>> >>> if I got that right the number of nodes is not<br>> >>> highly correlated to the img size, so the max-nodes<br>> >>> value is not a good estimate.<br>> >>><br>> >>> I assume the reason is that nodes which belong to<br>> >>> roads produce a lot more bytes<br>> >>> in the img file compared to nodes which are parts<br>> >>> of shapes or other non-routable ways, not talking<br>> >>> about nodes which are simply ignored by the style.<br>> >>><br>> >>> So, a possible solution in splitter could be to parse<br>> >>> the ways before reading the nodes and save all nodeids<br>> >>> which belong to ways with highway=*.<br>> >>> If these nodes are refered by more than one way with<br>> >>> highway=*<br>> >>> we assume that they will be routing nodes.<br>> >>> These special nodes could be counted e.g. 10 times to<br>> >>> give a better estimate.<br>> >>><br>> >>> Gerd<br>> >>><br>> >>> > Date: Wed, 30 Apr 2014 13:36:19 +0200<br>> >>> > From:<br>> >> osm@<br>> >> &lt;mailto:<br>> >> osm@<br>> >> &gt;<br>> >>> > To:<br>> >> mkgmap-dev@.org<br>> >>> &lt;mailto:<br>> >> mkgmap-dev@.org<br>> >> &gt;<br>> >>> > Subject: Re: [mkgmap-dev] mkgmap ToDo list<br>> >>> ><br>> >>> > Multithreading the tile rendering for a single map<br>> >>> is indeed a bit<br>> >>> > difficult and I gave it up because you need to keep<br>> >>> track which image<br>> >>> > id's are already in use. Since I provide multiple<br>> >>> maps the work-around<br>> >>> > is running a few scripts parallel, which is also a<br>> >>> crude form of<br>> >>> > multithreading.<br>> >>> ><br>> >>> > The script language is PHP and it doesn't run on<br>> >>> Windows without some<br>> >>> > changes ('/' vs '\' in paths, 'rm -rf', that sort of<br>> >>> stuff). Never tried it.<br>> >>> ><br>> >>> > To get a better optimum in file size, using the<br>> >>> process I described<br>> >>> > earlier, you could start off with a huge --max-nodes<br>> >>> setting and then<br>> >>> > 'search' for the highest --max-nodes that works for<br>> >>> each specific area.<br>> >>> ><br>> >>> > On 30/04/2014 11:49, Felix Hartmann wrote:<br>> >>> > > I would love if there was a possibility that you<br>> >>> pass the used max-nodes<br>> >>> > > value to mkgmap.<br>> >>> > > When mkgmap is compiling the maps, then after the<br>> >>> .img is created it<br>> >>> > > should check<br>> >>> > > a) did it crash due to too many max-nodes<br>> >>> > > b) for me not important - but for others with very<br>> >>> old GPS, etrex 10,<br>> >>> > > ---> is tile bigger than X (usually 8) MB.<br>> >>> > ><br>> >>> > > if a) or b) true, then pass the file back to<br>> >>> splitter and split with 60%<br>> >>> > > of maxnodes - and compile the resulting .img files<br>> >>> again. Should it fail<br>> >>> > > again, use 40%, again 25%... Sometimes there are<br>> >>> awful tiles, that need<br>> >>> > > supersmall max-nodes till they compile, however<br>> >>> lately (last 1-2 years)<br>> >>> > > I never encountered them anymore. I think that<br>> >>> happened rather due to a<br>> >>> > > but in splitter/mgkmap that is fixed now.<br>> >>> > ><br>> >>> > > okay, you could also do this with a script, but it<br>> >>> gets rather<br>> >>> > > complicated to multithread it (you need to wait<br>> >>> till mgkmap finished<br>> >>> > > compiling all .img files - and run mkgmap first<br>> >>> without address index to<br>> >>> > > save time) and do some clever routines on making<br>> >>> sure that the map id<br>> >>> > > (e.g. 6340????.img) stay correct. Even more<br>> >>> complicated to have<br>> >>> > > consequent map id...<br>> >>> > ><br>> >>> > > For europe with a fixed max-node I get tiles from<br>> >>> 1.9MB up to 18MB.<br>> >>> > > That's factor 9 - so it's huge...<br>> >>> > > If I could narrows that down easily to 8-18MB -<br>> >>> without getting tiles<br>> >>> > > crashing due to too high max-nodes values, that<br>> >>> would be sweet.<br>> >>> > ><br>> >>> > ><br>> >>> > ><br>> >>> > > As for the scripts - would they run on windows<br>> >>> too? - What programming<br>> >>> > > language are they in?<br>> >>> > ><br>> >>> > ><br>> >>> > > On 29.04.2014 21:39,<br>> >> osm@<br>> >>> &lt;mailto:<br>> >> osm@<br>> >> &gt; wrote:<br>> >>> > >> Oh, and ofcourse anyone interested can get my<br>> >>> scripts, send an email.<br>> >>> > >> They'll be on Github someday anyway.<br>> >>> > >><br>> >>> > >><br>> >>> > >> On 2014-04-29 20:37, Gerd Petermann wrote:<br>> >>> > >>> Hi Lambertus,<br>> >>> > >>><br>> >>> > >>> okay, if I got that right you finally get *.img<br>> >>> files with a size<br>> >>> > >>> near (but below) 8MB, so maybe Henning can use<br>> >>> that script, too.<br>> >>> > >>><br>> >>> > >>> If you do that for e.g. Germany, how small is<br>> >>> tpically the smallest<br>> >>> > >>> *.img file ?<br>> >>> > >>> Is it probably near 4 MB?<br>> >>> > >>><br>> >>> > >>> Gerd<br>> >>> > >>><br>> >>> > >>>> To:<br>> >> mkgmap-dev@.org<br>> >>> &lt;mailto:<br>> >> mkgmap-dev@.org<br>> >> &gt;<br>> >>> > >>>> Date: Tue, 29 Apr 2014 20:30:27 +0200<br>> >>> > >>>> From:<br>> >> osm@<br>> >> &lt;mailto:<br>> >> osm@<br>> >> &gt;<br>> >>> > >>>> Subject: Re: [mkgmap-dev] mkgmap ToDo list<br>> >>> > >>>><br>> >>> > >>>> These are the direct results from Splitter. The<br>> >>> format is o5m, both<br>> >>> > >>>> input as output. Splitter version is: r321.<br>> >>> > >>>><br>> >>> > >>>> For this test I split the original source with<br>> >>> --max-nodes=8000000.<br>> >>> > >>> Then<br>> >>> > >>>> I render the initial tiles, when the result is<br>> >>> larger than 8MB it's<br>> >>> > >>>> subsplit again with<br>> >>> --max-nodes=(8000000-(attempt*100000)). The<br>> >>> > >>> initial<br>> >>> > >>>> source files are ~70MB (o5m) and after several<br>> >>> subsplits the two<br>> >>> > >>> *.img<br>> >>> > >>>> are < 8MB. During this process --max-nodes has<br>> >>> been reduced to e.g.<br>> >>> > >>>> 7500000 and the source file is split up in two<br>> >>> o5m files of about<br>> >>> > >>> 37MB.<br>> >>> > >>>><br>> >>> > >>>> I can upload an example source file and it's<br>> >>> two subsplit siblings<br>> >>> > >>> if<br>> >>> > >>>> you want.<br>> >>> > >>>><br>> >>> > >>>><br>> >>> > >>>> On 2014-04-29 19:38, GerdP wrote:<br>> >>> > >>>> > Hi Lambertus,<br>> >>> > >>>> ><br>> >>> > >>>> > that's interesting. Are these the img file<br>> >>> sizes or the osm file<br>> >>> > >>> sizes?<br>> >>> > >>>> ><br>> >>> > >>>> > Gerd<br>> >>> > >>>> ><br>> >>> > >>>> ><br>> >>> > >>>> > Lambertus wrote<br>> >>> > >>>> >> Unfortunately I cannot confirm that. Below<br>> >>> is a bit of logging<br>> >>> > >>> from my<br>> >>> > >>>> >> script:<br>> >>> > >>>> >> Original: 97000020 (70551453), New: 0<br>> >>> (35684445), New: 1<br>> >>> > >>> (36852845)<br>> >>> > >>>> >> Original: 97000001 (74621042), New: 0<br>> >>> (37522992), New: 1<br>> >>> > >>> (37222739)<br>> >>> > >>>> >> Original: 97000002 (73391358), New: 0<br>> >>> (37679505), New: 1<br>> >>> > >>> (38098627)<br>> >>> > >>>> >> Original: 97000003 (77862567), New: 0<br>> >>> (39075311), New: 1<br>> >>> > >>> (39261197)<br>> >>> > >>>> >><br>> >>> > >>>> >> The original files above contain contour<br>> >>> data, the filesize is<br>> >>> > >>> between<br>> >>> > >>>> >> brackets. As you can see both resulting file<br>> >>> are approximately<br>> >>> > >>> the<br>> >>> > >>>> >> same<br>> >>> > >>>> >> size.<br>> >>> > >>>> >><br>> >>> > >>>> >> On 2014-04-29 15:39, Gerd Petermann wrote:<br>> >>> > >>>> >>> Hi Lambertus,<br>> >>> > >>>> >>><br>> >>> > >>>> >>> and I guess that even after this<br>> >>> optimization you will<br>> >>> > >>>> >>> see a factor 3 or higher between the<br>> >>> largest tile and the<br>> >>> > >>> smallest.<br>> >>> > >>>> >>> Can you confirm that?<br>> >>> > >>>> >>><br>> >>> > >>>> >>> Gerd<br>> >>> > >>>> >>><br>> >>> > >>>> >>>> Date: Tue, 29 Apr 2014 15:32:38 +0200<br>> >>> > >>>> >>>> From:<br>> >>> > >>>> ><br>> >>> > >>>> >> osm@<br>> >>> > >>>> ><br>> >>> > >>>> >>>> To:<br>> >>> > >>>> ><br>> >>> > >>>> >> mkgmap-dev@.org &lt;mailto:mkgmap-dev@.org&gt;<br>> >>> > >>>> ><br>> >>> > >>>> >>>> Subject: Re: [mkgmap-dev] mkgmap ToDo list<br>> >>> > >>>> >>>><br>> >>> > >>>> >>>> Num-tiles=x would indeed be better for<br>> >>> this specific need.<br>> >>> > >>>> >>>><br>> >>> > >>>> >>>> It is my experience that it regularly<br>> >>> takes multiple calls to<br>> >>> > >>>> >>> Splitter<br>> >>> > >>>> >>>> to get 2+ sub-tiles when you reduce the<br>> >>> max-nodes by 100k for<br>> >>> > >>> each<br>> >>> > >>>> >>>> sub-split attempt. This is what I<br>> >>> currently do to get an<br>> >>> > >>> optimum in<br>> >>> > >>>> >>>> tile-size vs total number of tiles.<br>> >>> > >>>> >>>><br>> >>> > >>>> >>>><br>> >>> > >>>> >>>><br>> >>> > >>>> >>>> On 29/04/2014 15:09, Gerd Petermann wrote:<br>> >>> > >>>> >>>> > Hi Lambertus,<br>> >>> > >>>> >>>> ><br>> >>> > >>>> >>>> > that sounds like a possible change in<br>> >>> splitter:<br>> >>> > >>>> >>>> > Instead of specifying max-nodes you may<br>> >>> specify --num-tiles=x<br>> >>> > >>>> >>>> > and splitter will try to find a split<br>> >>> that produces excactly<br>> >>> > >>> x<br>> >>> > >>>> >>> tiles<br>> >>> > >>>> >>>> > which are not too narrow and have a node<br>> >>> number which is not<br>> >>> > >>>> >>>> > too far from the average (but still<br>> >>> aligned to a multiple of<br>> >>> > >>> map<br>> >>> > >>>> >>> units<br>> >>> > >>>> >>>> > as now).<br>> >>> > >>>> >>>> > So, for your script that means you don't<br>> >>> have to find the<br>> >>> > >>>> >>> max-nodes<br>> >>> > >>>> >>>> > value.<br>> >>> > >>>> >>>> ><br>> >>> > >>>> >>>> > I'll think about this again...<br>> >>> > >>>> >>>> ><br>> >>> > >>>> >>>> > Gerd<br>> >>> > >>>> >>>> ><br>> >>> > >>>> >>>> > > Date: Tue, 29 Apr 2014 14:59:36 +0200<br>> >>> > >>>> >>>> > > From:<br>> >>> > >>>> ><br>> >>> > >>>> >> osm@<br>> >>> > >>>> ><br>> >>> > >>>> >>>> > > To:<br>> >>> > >>>> ><br>> >>> > >>>> >> mkgmap-dev@.org &lt;mailto:mkgmap-dev@.org&gt;<br>> >>> > >>>> ><br>> >>> > >>>> >>>> > > Subject: Re: [mkgmap-dev] mkgmap ToDo<br>> >>> list<br>> >>> > >>>> >>>> > ><br>> >>> > >>>> >>>> > > While this possibly can be solved in<br>> >>> Splitter or Mkgmap, it<br>> >>> > >>>> >>> could also<br>> >>> > >>>> >>>> > > be solved by your build-script when<br>> >>> you add a maximum tile<br>> >>> > >>> size<br>> >>> > >>>> >>> check<br>> >>> > >>>> >>>> > > and re-split (with a lower number of<br>> >>> max-nodes) until you<br>> >>> > >>> get<br>> >>> > >>>> >>> two or<br>> >>> > >>>> >>>> > > more sub-tiles. Granted, this adds<br>> >>> complexity to the script<br>> >>> > >>> but<br>> >>> > >>>> >>> it works<br>> >>> > >>>> >>>> > > well for me.<br>> >>> > >>>> >>>> > ><br>> >>> > >>>> >>>> > > On 25/04/2014 21:54, Henning Scholland<br>> >>> wrote:<br>> >>> > >>>> >>>> > > > Hi Gerd,<br>> >>> > >>>> >>>> > > ><br>> >>> > >>>> >>>> > > > I would like to have img-tiles which<br>> >>> have globally nearly<br>> >>> > >>> the<br>> >>> > >>>> >>> same<br>> >>> > >>>> >>>> > > > filesize, so that they use the space<br>> >>> of devices like<br>> >>> > >>> eTrex 10.<br>> >>> > >>>> >>>> > > ><br>> >>> > >>>> >>>> > > > With my actual map I use globally<br>> >>> the same value for<br>> >>> > >>>> >>> max-nodes. But the<br>> >>> > >>>> >>>> > > > size of the img-tiles differ more<br>> >>> then factor 2. Eg. a<br>> >>> > >>> tile in<br>> >>> > >>>> >>> Germany<br>> >>> > >>>> >>>> > > > is between 2 and 5 mb where a tile<br>> >>> in China is about 10<br>> >>> > >>> mb. If<br>> >>> > >>>> >>> I remove<br>> >>> > >>>> >>>> > > > details, this difference will<br>> >>> increase, because in<br>> >>> > >>> Germany<br>> >>> > >>>> >>> more objects<br>> >>> > >>>> >>>> > > > will be removed from the img-tile<br>> >>> then in China.<br>> >>> > >>>> >>>> > > ><br>> >>> > >>>> >>>> > > > Henning<br>> >>> > >>>> >>>> > > ><br>> >>> > >>>> >>>> > > ><br>> >>> _______________________________________________<br>> >>> > >>>> >>>> > > > mkgmap-dev mailing list<br>> >>> > >>>> >>>> > > ><br>> >>> > >>>> ><br>> >>> > >>>> >> mkgmap-dev@.org &lt;mailto:mkgmap-dev@.org&gt;<br>> >>> > >>>> ><br>> >>> > >>>> >>>> > > ><br>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>> > >>>> >>>> > ><br>> >>> > >>>> >>>> > ><br>> >>> _______________________________________________<br>> >>> > >>>> >>>> > > mkgmap-dev mailing list<br>> >>> > >>>> >>>> > ><br>> >>> > >>>> ><br>> >>> > >>>> >> mkgmap-dev@.org &lt;mailto:mkgmap-dev@.org&gt;<br>> >>> > >>>> ><br>> >>> > >>>> >>>> > ><br>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>> > >>>> >>>> ><br>> >>> > >>>> >>>> ><br>> >>> > >>>> >>>> ><br>> >>> _______________________________________________<br>> >>> > >>>> >>>> > mkgmap-dev mailing list<br>> >>> > >>>> >>>> ><br>> >>> > >>>> ><br>> >>> > >>>> >> mkgmap-dev@.org &lt;mailto:mkgmap-dev@.org&gt;<br>> >>> > >>>> ><br>> >>> > >>>> >>>> ><br>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>> > >>>> >>>> ><br>> >>> > >>>> >>>><br>> >>> > >>>> >>>><br>> >>> _______________________________________________<br>> >>> > >>>> >>>> mkgmap-dev mailing list<br>> >>> > >>>> >>>><br>> >>> > >>>> ><br>> >>> > >>>> >> mkgmap-dev@.org &lt;mailto:mkgmap-dev@.org&gt;<br>> >>> > >>>> ><br>> >>> > >>>> >>>><br>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>> > >>>> >>><br>> >>> > >>>> >>><br>> >>> _______________________________________________<br>> >>> > >>>> >>> mkgmap-dev mailing list<br>> >>> > >>>> >>><br>> >>> > >>>> ><br>> >>> > >>>> >> mkgmap-dev@.org &lt;mailto:mkgmap-dev@.org&gt;<br>> >>> > >>>> ><br>> >>> > >>>> >>><br>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>> > >>>> >> _______________________________________________<br>> >>> > >>>> >> mkgmap-dev mailing list<br>> >>> > >>>> ><br>> >>> > >>>> >> mkgmap-dev@.org &lt;mailto:mkgmap-dev@.org&gt;<br>> >>> > >>>> ><br>> >>> > >>>> >><br>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>> > >>>> ><br>> >>> > >>>> ><br>> >>> > >>>> ><br>> >>> > >>>> ><br>> >>> > >>>> ><br>> >>> > >>>> > --<br>> >>> > >>>> > View this message in context:<br>> >>> > >>>> ><br>> >>> > >>><br>> >>> <br>> >>> http://gis.19327.n5.nabble.com/mkgmap-ToDo-list-tp5803388p5804588.html<br>> >>> > >>>> > Sent from the Mkgmap Development mailing list<br>> >>> archive at<br>> >>> > >>> Nabble.com.<br>> >>> > >>>> > _______________________________________________<br>> >>> > >>>> > mkgmap-dev mailing list<br>> >>> > >>>> ><br>> >> mkgmap-dev@.org<br>> >>> &lt;mailto:<br>> >> mkgmap-dev@.org<br>> >> &gt;<br>> >>> > >>>> ><br>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>> > >>>> _______________________________________________<br>> >>> > >>>> mkgmap-dev mailing list<br>> >>> > >>>><br>> >> mkgmap-dev@.org<br>> >>> &lt;mailto:<br>> >> mkgmap-dev@.org<br>> >> &gt;<br>> >>> > >>>><br>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>> > >>><br>> >>> > >>> _______________________________________________<br>> >>> > >>> mkgmap-dev mailing list<br>> >>> > >>><br>> >> mkgmap-dev@.org<br>> >>> &lt;mailto:<br>> >> mkgmap-dev@.org<br>> >> &gt;<br>> >>> > >>><br>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>> > >> _______________________________________________<br>> >>> > >> mkgmap-dev mailing list<br>> >>> > >><br>> >> mkgmap-dev@.org<br>> >>> &lt;mailto:<br>> >> mkgmap-dev@.org<br>> >> &gt;<br>> >>> > >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>> > ><br>> >>> ><br>> >>> > _______________________________________________<br>> >>> > mkgmap-dev mailing list<br>> >>> ><br>> >> mkgmap-dev@.org<br>> >>> &lt;mailto:<br>> >> mkgmap-dev@.org<br>> >> &gt;<br>> >>> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>><br>> >>><br>> >>> _______________________________________________<br>> >>> mkgmap-dev mailing list<br>> >>> <br>> >> mkgmap-dev@.org<br>> >> &lt;mailto:<br>> >> mkgmap-dev@.org<br>> >> &gt;<br>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>><br>> >>><br>> >>> --<br>> >>> keep on biking and discovering new trails<br>> >>><br>> >>> Felix<br>> >>> openmtbmap.org &www.velomap.org<br>> >>> &lt;http://www.velomap.org&gt;<br>> >>><br>> >>><br>> >>> _______________________________________________ mkgmap-dev<br>> >>> mailing list<br>> >> mkgmap-dev@.org<br>> >>> &lt;mailto:<br>> >> mkgmap-dev@.org<br>> >> &gt;<br>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>><br>> >>><br>> >>> _______________________________________________<br>> >>> mkgmap-dev mailing list<br>> >>> <br>> >> mkgmap-dev@.org<br>> >> &lt;mailto:<br>> >> mkgmap-dev@.org<br>> >> &gt;<br>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>><br>> >>><br>> >>> --<br>> >>> keep on biking and discovering new trails<br>> >>><br>> >>> Felix<br>> >>> openmtbmap.org &www.velomap.org &lt;http://www.velomap.org&gt;<br>> >>><br>> >>><br>> >>> _______________________________________________ mkgmap-dev<br>> >>> mailing list<br>> >> mkgmap-dev@.org<br>> >>> &lt;mailto:<br>> >> mkgmap-dev@.org<br>> >> &gt;<br>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>><br>> >>><br>> >>> _______________________________________________<br>> >>> mkgmap-dev mailing list<br>> >>> <br>> >> mkgmap-dev@.org<br>> >> &lt;mailto:<br>> >> mkgmap-dev@.org<br>> >> &gt;<br>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>><br>> >>><br>> >>><br>> >>> _______________________________________________ mkgmap-dev mailing<br>> >>> list<br>> >> mkgmap-dev@.org<br>> >>> &lt;mailto:<br>> >> mkgmap-dev@.org<br>> >> &gt;<br>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>><br>> >>><br>> >>> _______________________________________________<br>> >>> mkgmap-dev mailing list<br>> >>> <br>> >> mkgmap-dev@.org<br>> >> &lt;mailto:<br>> >> mkgmap-dev@.org<br>> >> &gt;<br>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>><br>> >>><br>> >>><br>> >>> _______________________________________________ mkgmap-dev mailing<br>> >>> list<br>> >> mkgmap-dev@.org<br>> >> <br>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >>><br>> >>><br>> >>> _______________________________________________<br>> >>> mkgmap-dev mailing list<br>> >>><br>> >> mkgmap-dev@.org<br>> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >> -- <br>> >> keep on biking and discovering new trails<br>> >><br>> >> Felix<br>> >> openmtbmap.org & www.velomap.org<br>> >><br>> >><br>> >> _______________________________________________<br>> >> mkgmap-dev mailing list<br>> >> mkgmap-dev@.org<br>> >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> ><br>> ><br>> ><br>> ><br>> > --<br>> > View this message in context: http://gis.19327.n5.nabble.com/mkgmap-ToDo-list-tp5803388p5805221.html<br>> > Sent from the Mkgmap Development mailing list archive at Nabble.com.<br>> > _______________________________________________<br>> > mkgmap-dev mailing list<br>> > mkgmap-dev@lists.mkgmap.org.uk<br>> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> <br>> -- <br>> keep on biking and discovering new trails<br>> <br>> Felix<br>> openmtbmap.org & www.velomap.org<br>> <br>> _______________________________________________<br>> mkgmap-dev mailing list<br>> mkgmap-dev@lists.mkgmap.org.uk<br>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br></div> </div></body>
</html>