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