February 2017 - mkgmap-dev - The mkgmap lists

Commit r3808: improve performance of ShapeMergeFilter
by svn commit 15 Feb '17

15 Feb '17

Version mkgmap-r3808 was committed by gerd on Wed, 15 Feb 2017 improve performance of ShapeMergeFilter The old code didn't work well when many (e.g. 1000+) distinct similar shapes were processed (e.g. buildings). This typically happens only when style adds shapes at low resolutions. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3808

1 0

Commit r3806: small performance improvement: Don't call Coord.toDegreeString() when result is not needed
by svn commit 15 Feb '17

15 Feb '17

Version mkgmap-r3806 was committed by gerd on Wed, 15 Feb 2017 small performance improvement: Don't call Coord.toDegreeString() when result is not needed http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3806

1 0

Commit r3804: remove echotags from defautl style (was for debugging only)
by svn commit 15 Feb '17

15 Feb '17

Version mkgmap-r3804 was committed by gerd on Mon, 13 Feb 2017 remove echotags from defautl style (was for debugging only) http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3804

3 3

Commit r3805: correction: don't add null to usedTags collection for style functions like is_closed() or area_size()
by svn commit 15 Feb '17

15 Feb '17

Version mkgmap-r3805 was committed by gerd on Wed, 15 Feb 2017 correction: don't add null to usedTags collection for style functions like is_closed() or area_size() http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3805

1 0

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

14 Feb '17

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(MapSplitter. > > 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 >

1 0

RE Commit r3801: merge split-shape branch
by Mike Baggaley 14 Feb '17

14 Feb '17

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(MapSplitter.java: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

2 1

Commit r3803: tags_sorted.patch : print tags ordered by key names
by svn commit 13 Feb '17

13 Feb '17

Version mkgmap-r3803 was committed by gerd on Mon, 13 Feb 2017 tags_sorted.patch : print tags ordered by key names This effects the echotags style function and logging, not the map created by mkgmap. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3803

1 0

Commit r3802: surface_v7.patch: change detection of unpaved roads for default style
by svn commit 13 Feb '17

13 Feb '17

Version mkgmap-r3802 was committed by gerd on Mon, 13 Feb 2017 surface_v7.patch: change detection of unpaved roads for default style http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3802

1 0

Commit r3801: merge split-shape branch
by svn commit 13 Feb '17

13 Feb '17

Version mkgmap-r3801 was committed by gerd on Mon, 13 Feb 2017 merge split-shape branch http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3801

1 0

construction as industry?
by nwillink 10 Feb '17

10 Feb '17

Hi I just realised that in the default polygon style construction, whether its residential or industrial , is always defined as industrial 0x0c. I understand the' logic' , in that there are many 'mobile' industries constructing residential or industrial buildings. In my city there are numerous large construction sites, all of them constructing residential housing. If I were unknown to the city and plan a route through an industrial area I would expect to find the following : a) industrial blocks / units / working businesses b) roads entering and crossing industrial areas safe from barriers,fencing,cones,mud-sweepers,grumpiness or foremen etc Personally I would provide a separate polygon , ie 0x27 perhaps Just a thought. Nick -- View this message in context: http://gis.19327.n8.nabble.com/construction-as-industry-tp5890573.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 4