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

Sat Oct 22 14:16:49 BST 2016

Hi Ticker,

great, enjoy your holidays!

Gerd

Ticker Berkin wrote
> 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 .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

--
View this message in context: http://gis.19327.n8.nabble.com/patch-to-write-polygons-in-decreasing-order-tp5884038p5884778.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.