Re: [mkgmap-dev] splitter r448 in refactoring2 branch

2016-11-28 Thread Steve Ratcliffe
On 28/11/16 16:40, Steve Ratcliffe wrote: but attempting to download the release fails. The branch releases are currently being named splitter-r447.zip etc without the branch name. I manually renamed the splitter-refactoring2-r448.tar.gz file so it can now be downloaded. I will fix up so that

Re: [mkgmap-dev] splitter r448 in refactoring2 branch

2016-11-28 Thread Steve Ratcliffe
Hi Gerd @Steve: Please can you check why is it not working? Oh I see it builds, but attempting to download the release fails. http://www.mkgmap.org.uk/mkgmap/splitter/build I'll take a look at the download, I don't think there has been a branch build since the last web site update. ..Steve

[mkgmap-dev] splitter r448 in refactoring2 branch

2016-11-28 Thread Gerd Petermann
Hi all, I've started a new branch to implement some improvements for splitter. Unfortunately the automatic build doesn't seem to work. @Steve: Please can you check why is it not working? Gerd -- View this message in context:

[mkgmap-dev] Commit r3706: set mkgmap:drawLevel=2 for natural=sea polygons

2016-11-28 Thread svn commit
Version mkgmap-r3706 was committed by gerd on Mon, 28 Nov 2016 set mkgmap:drawLevel=2 for natural=sea polygons - was like that in the patch by Ticker Berkin http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=3706 ___ mkgmap-dev mailing list

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

2016-11-28 Thread Ticker Berkin
Hi Gerd No, it shouldn't make any difference. It was more like documentation and a pointer to where the tag was used and could be changed. But I wasn't sure about all the ways sea polygons could come into being and so having this ensured the same area was always set. It also matches a comment in

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

2016-11-28 Thread Gerd Petermann
Gerd Petermann wrote > this was not intended, I mixed my own tests with your patch. That was probably too short. I committed your change together with my own test changes in r3704 and reverted both with r3705. Do you think that the change in inc/is mandantory when --order-by-decreasing-area is

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

2016-11-28 Thread Ticker Berkin
Hi Gerd No - this was the only occurrence. Ticker On Mon, 2016-11-28 at 02:38 -0700, Gerd Petermann wrote: > Hi Ticker, > > this was not intended, I mixed my own tests with your patch. > Did you try to use mkgmap:drawLevel for other polygons, e.g. > buildings? > > Gerd > > Ticker Berkin

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

2016-11-28 Thread Gerd Petermann
Hi Ticker, this was not intended, I mixed my own tests with your patch. Did you try to use mkgmap:drawLevel for other polygons, e.g. buildings? Gerd Ticker Berkin wrote > Hi Gerd, > > Just noticed that you didn't include the change to > resources/styles/default/inc/water_polygons that was in

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

2016-11-28 Thread Ticker Berkin
Hi Gerd, Just noticed that you didn't include the change to resources/styles/default/inc/water_polygons that was in drawLevel_v2.patch -natural=sea { add mkgmap:skipSizeFilter=true } [0x32 resolution 10] +natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x32 resolution 10]