- mkgmap-dev - The mkgmap lists

Commit r3822: Correct style evaluation index
by svn commit 27 Feb '17

27 Feb '17

Version mkgmap-r3822 was committed by gerd on Mon, 27 Feb 2017 Correct style evaluation index In special cases matching rules were not evaluated, e.g. for the following three rules boundary=administrative { set mkgmap:if:0001=1 } admin_level<3 & mkgmap:if:0001=1 [0x1e resolution 12] mkgmap:if:0001!=1 & admin_level<3 [0x1f resolution 14] a way with the tags boundary=xyz and admin_level=2 should trigger the last rule, but it did not. The problem was in the evaluation of so-called changable tags (mkgmap:if:0001 in this case). The effect of this correction is that the index returns more rules for evaluation and probably a small increase in the run time. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3822

1 0

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
by Ticker Berkin 26 Feb '17

26 Feb '17

Hi Mike OK - I think I understand the problem. Can you try with --order-by-decreasing-area and let me know if that stops the unbound recursion, and, in the meantime, I'll work on it. Thanks Ticker On Wed, 2017-02-15 at 00:48 +0000, Mike Baggaley wrote: > HI Ticker, having run this under the debugger now, it appears that it > is not the postcode data after all - I was getting confused between > the too small to split messages and too many POIs messages. I was > previously getting too small to split messages in splitter, but not > in mkgmap. > > I temporarily changed the code to: > > } else if (mustSplit) { // can't reduce > size, so force more subdivisions > if (depth < 1000) { > log.debug("splitting > area by contents", area); > MapArea[] sublist = > area.split(1, 1, bounds, true); > addAreasToList(sublist, > alist, depth + 1); > continue; > } else { > log.error("Area too > small to split at " + area.getBounds().getCenter().toOSMURL() + " > (reduce the density of points, length of lines, etc.)"); > > } > } > > This ran successfully and gave a single error: > Area too small to split at > http://www.openstreetmap.org/?mlat=51.797190&mlon=0.918646&zoom=17 (r > educe the density of points, length of lines, etc. > > Stopping in the debugger, I can see that sizes[MapArea.SHAPE_KIND] is > 68076 and from the coordinate it is processing the coastline. The > call stack has the same value for the sizes[MapArea.SHAPE_KIND] in > every instance of addAreasToList, so it looks like the call to > area.split is not actually splitting. Looking at the resulting file > in BaseCamp, I can see that the coastline is corrupt. > > Hope that helps, > Mike > > -----Original Message----- > From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] > Sent: 14 February 2017 23:21 > To: Mike Baggaley <mike(a)tvage.co.uk> > Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch > > Hi Mike > > I have the raw postcode data (codePointOpen.zip) which I processes > just > to take the first few at the same point but I can change it do all of > them individually. Do you feed it with a map through the splitter or > just make a postcode only overlay? What is the bit of style you use > to > represent each postcode? I can probably knock up something similar. > > The code should cope - I can't see anything obviously wrong so need > to > try and reproduce the problem > > Ticker > > On Tue, 2017-02-14 at 18:17 +0000, Mike Baggaley wrote: > > Hi Ticker the data is postcode centres (points). As well as > > geographic postcodes, the Royal Mail postcode data includes a > > number > > of postcodes that are centred on sorting offices (presumably for > > box > > numbers). There are quite a few at large sorting offices, but if > > each > > split should be able to accept 255 points, and it is exceeding 2000 > > splits before crashing, it looks like the splitting is not working > > - > > there won't be more than 2000 * 255 postcodes at the same place. My > > OSM file is rather large. I can see whether I can extract a map > > centred on a sorting office. > > > > Regards, > > Mike > > > > -----Original Message----- > > From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] > > Sent: 14 February 2017 17:52 > > To: mkgmap-dev(a)lists.mkgmap.org.uk > > Subject: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch > > > > Hi Mike > > > > This is an area of code I've changed and it should be able to cope > > with > > many items at the same location without recursing. > > > > Do you have some sample data? what are the items (point/line/shape > > extended?) > > > > Ticker > > > > On Tue, 2017-02-14 at 17:40 +0000, Mike Baggaley wrote: > > > Hi Gerd, since this change I am getting a > > > java.lang.StackOverflowError crash > > > caused by the code recursively attempting to split something > > > which > > > is > > > unsplittable (assuming the split is based on location), as I have > > > a > > > large > > > number of points at exactly the same location (from external data > > > I > > > add to > > > the OSM data). > > > > > > The offending line is at > > > uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitte > > > r. > > > ja > > > va:187) > > > . It is failing on my system with a depth of 2342. I suggest > > > there > > > needs to > > > be a maximum depth after which it should give up trying to split. > > > > > > } else if (mustSplit) { // can't reduce > > > size, so force more subdivisions > > > log.debug("splitting area by > > > contents", area); > > > MapArea[] sublist = > > > area.split(1, 1, > > > bounds, true); > > > addAreasToList(sublist, alist, > > > depth > > > + 1); > > > continue; > > > } > > > > > > I am unsure whether you would want a fixed depth limit, would > > > want > > > it > > > to be > > > set by parameter, would prefer to catch the error or think it > > > would > > > be > > > possible to see whether the proposed area split has made any > > > improvement, > > > and give up if it hasn't. > > > > > > Regards, > > > Mike > > > > > > > > > _______________________________________________ > > > mkgmap-dev mailing list > > > mkgmap-dev(a)lists.mkgmap.org.uk > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > >

4 28

[Patches] if-then and rule-index
by Gerd Petermann 25 Feb '17

25 Feb '17

Hi, Attached are two patches to address some of the problems in the if-then branch. - rule_index_v1.patch: This changes the index so that the example posted here works: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q1/026311.html I guess it will have a small impact on performance because it is likely that more rules are evaluated. - if-then-reader-v1.patch This addresses the problems posted here: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q1/026290.html The unpatched code created a new ExpressionReader for the expressions in the if statement instead of using the existing one. As a result, the getUsedTags() method did not return all used tags. Gerd

1 0

Terraced/pixellated coastline with --precomp-sea
by NopMap 24 Feb '17

24 Feb '17

Hello, I am trying to switch to --precomp-sea instead of generating the coastline directly from OSM data. For higher zoomlevels this works fine. For lower zoomlevels (scale in basecamp >=5km) the coastline appears heavily terraced/pixellated. Playing with parameters like poly reduction did not change this behaviour. Here's a screenshot <http://www.wanderreitkarte.de/download/coastline_steps.png> . The real coastline from OSM data is visible as a dotted line. The coastline generated from OSM at the same zoomlevel looks somewhat jagged from polygon reduction, but is not terraced in any way. mkgmap versions: 3366 and 3796 sea file downloaded from mkgmap page <http://osm2.pleiades.uni-wuppertal.de/sea/latest/sea.zip> , 13.2.17 command line: java -jar mkgmap.jar --tdbfile --preserve-element-order --precomp-sea=p:\Input\sea.zip --generate-sea -c osmc_options There are no sea parameters in the option file, poly reduction is at default levels. Any ideas? -- View this message in context: http://gis.19327.n8.nabble.com/Terraced-pixellated-coastline-with-precomp-s… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 9

Commit r3820: reformat source, no functional change
by svn commit 23 Feb '17

23 Feb '17

Version mkgmap-r3820 was committed by gerd on Thu, 23 Feb 2017 reformat source, no functional change http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3820

1 0

To do: If-Then-Else
by Dave Swarthout 22 Feb '17

22 Feb '17

I came across the mkgmap ToDo list the other day and one item struck me as something I would really like to see in a coming release. The ability to evaluate If-Then-Else constructs would make writing, evaluating and debugging style rules so much easier. +1 on this item Also, a little clarification please. The list item says: - conditional includes in style files and/or if else statements I don't understand this statement. Perhaps it's because I'm assuming a "conditional include" means: If (condition) Then include 'inc/address'; Or does it mean, for example, If (condition) { add mkgmap:unpaved=1 } Thank you in advance. AlaskaDave -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com

7 24

Commit r3819: fix typo: use int instead of double for duplicate point detection
by svn commit 22 Feb '17

22 Feb '17

Version mkgmap-r3819 was committed by gerd on Wed, 22 Feb 2017 fix typo: use int instead of double for duplicate point detection No change in output expected, but maybe a minimal performance impact http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3819

1 0

Commit r3818: code improvements, no change in output expected
by svn commit 22 Feb '17

22 Feb '17

Version mkgmap-r3818 was committed by gerd on Wed, 22 Feb 2017 code improvements, no change in output expected - add constant Area PLANET - add some unit tests to detect problems with > 30 bits resolution - initialize minlat/minlon etc. with Integer.MAX(MIN)_VALUE http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3818

1 0

unpaved roads
by Gerd Petermann 22 Feb '17

22 Feb '17

Hi all, I noticed that the wiki http://wiki.openstreetmap.org/wiki/Key:surface mentions a few more surface values which are considered unpaved compared to the default style. The current rule in the lines file contains this highway=* & (surface=cobblestone | surface=compacted | surface=dirt | surface=earth | surface=grass | surface=grass_paver | surface=gravel | surface=grit | surface=ground | surface=mud | surface=pebblestone | surface=sand | surface=unpaved | mtb:scale=* | tracktype ~ 'grade[2-6]' | smoothness ~ '.*(bad|horrible|impassable)' | sac_scale ~ '.*(mountain|alpine)_hiking' | sport=via_ferrata) { add mkgmap:unpaved=1 } The wiki also llists these as unpaved: gravel_turf , fine_gravel, ice, salt, snow, woodchips I think the rule should at least contain gravel_turf, snow, and woodchips. My understanding is that fine_gravel, ice , and salt are rather smooth surfaces. Comments? Gerd -- View this message in context: http://gis.19327.n8.nabble.com/unpaved-roads-tp5890722.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

7 16

aeroway in default style
by Andrzej Popowski 21 Feb '17

21 Feb '17

Hi, I'm attaching proposed patch for aeroways. It corrects following problems: - aeroway is a highway, example http://www.openstreetmap.org/way/23832044 - aeroway=runway is an area, example http://www.openstreetmap.org/way/306366732 Patch also adds support for aeroway=taxilane and aeroway=heliport. -- Best regards, Andrzej

3 9