[mkgmap-dev] patch to write polygons in decreasing order

Sat Oct 22 14:00:09 BST 2016

Hi Gerd

I've reproduced the crash.

I think the problem is that area.getEstimatedSizes() (called from
MapSplitter.addAreasToList) doesn't reflects what will go into the area
when the option is in effect and so addAreasToList might keep
recursing.

I need to think about this more deeply. There is a related issue where
complex shapes are split earlier when there probably is no need because
they will be split later to scattered into lots of subDivisions.

Concerning the other problems:

It wasn't dead code - rather a function with side effects - I'll re
-code it.

Sorry about Long vs long.

I notice ShapeMergeFilterTest in the patch. I experimented a bit with
mergeShapes and was surprised it wasn't doing a bit of merging when my
option was in effect - I was expecting it join bits of the complex
shapes mentioned earlier.

I'm away on holiday next week. I should be able to send you something
in a couple of weeks time.

Regards
Ticker

On Sat, 2016-10-22 at 01:04 -0700, Gerd Petermann wrote:
> Hi Ticker,
> 
> I reviewed  the patch, it looked good but the patched version crashes
> in a
> recursion because of an 
> java.lang.StackOverflowError. I think the problem is in the rounding
> in Area
> class.
> I've uploaded test data that should allow you to reproduce the
> problem:
> http://files.mkgmap.org.uk/download/310/test.zip
> 
> Besides that I found two small problems:
> 1) The unit tests did not compile with the patch
> 2)  MultPpolygonRelation.java contains dead (?) code and uses Long
> instead
> of long.
> Please check my changes in the attached modified patch:
> 
> sortAreas_v2.patch
> <http://gis.19327.n8.nabble.com/file/n5884759/sortAreas_v2.patch>  ;
> 
> Ciao,
> Gerd
> 
> 
> Ticker Berkin wrote
> > Hi
> > 
> > I have a patch that outputs polygons into the map file in
> > decreasing
> > size order, so that, assuming equal _drawOrder, the Garmin device
> > renders small details over larger areas, much like how they appear
> > on
> > OpenStreetMap.org.
> > 
> > As well	as sorting by size, polygons that straddle
> > subDivisions	
> > are cut up and placed into their correct subdivision, rather than
> > being
> > put into an arbirary one, which, if it isn't the one in focus,
> > renders
> > over the focus subdivision.
> > 
> > The original, full, area of polygons is tracked	through	
> > a
> > ny cutting and clipping so that relative ordering is correct across
> > subdivision and map boundaries.
> > 
> > All this is controlled by the option --order-by-decreasing-area,
> > with a
> > default of false that leaves the behavior of mkgmap unchanged.	
> > A
> > s such, I think this patch could be applied to the trunk
> > development.
> > 
> > Regards
> > Ticker Berkin
> > mk
> > 
> > _______________________________________________
> > mkgmap-dev mailing list
> 
> > mkgmap-dev at .org
> 
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > 
> > sortAreas.patch (25K)
> > <http://gis.19327.n8.nabble.com/attachment/5884038/0/sortAreas.p
> > atch>
> 
> 
> 
> 
> 
> --
> View this message in context: http://gis.19327.n8.nabble.com/patch-to
> -write-polygons-in-decreasing-order-tp5884038p5884759.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