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

Fri Nov 11 14:56:14 GMT 2016

Hi Gerd

I think the reason why the buildings look different is because, without
--order-by-decreasing-area, they get merged into a single area and then
a filter (DouglasPeucker), finding the intermediate points are within
the tolerance of a straight line, removes all but the 4 corners of the
complete block. With --order-by, they are output individually as
accurately as possible, but, because we are at/beyond at the limit of
accuracy, rounding effects become obvious.

You mentioned GPSMapEdit not showing the smaller shape on top of the
larger. Using it to look at your test case of buildings in Bremen, and
the difference between with/without the option, I think it might apply
the size rule itself - drawing smaller shapes on top of larger. The
example I found was Penny supermarket @ 53.06650,8.79501 straddling a
number of buildings. With the buildings merged, it is smaller and hence
shows. With them separate, the buildings are smaller and they show.
Does this fit with your observations? Which examples were you looking
at? www.openstreetmap.org doesn't show Penny either.

I didn't use Util.roundUp because I wanted something to round to the
closest power of 2 and it rounds up to the next power of 2. I've
improved the javaDoc text for roundPof2.

I've made the other changes and attach a patch.

Regards
Ticker

On Fri, 2016-11-11 at 11:37 +0000, Ticker Berkin wrote:
> Hi Gerd
> 
> I'll check on the rounding, fix the warn>debug and add the pre-test
> to
> the splitting into areas.
> 
> I've just loaded GPSMapEdit and see what you mean about the long
> lines
> of buildings - they are wavy!. I'll work out why it is happening.
> 
> Regards
> Ticker 
>  
> On Fri, 2016-11-11 at 01:25 -0700, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > sorry, still some problems:
> > 1) I think I found an error in method Area.roundPof2(int val, int
> > shift)
> > I wanted to find out why you did not use Util.roundUp(int val, int
> > shift). 
> > 
> > For val=-9567 and shift=4 I see 
> > -9568 from your routine and
> > -9552 from the other
> > So it seems your routine doesn't round up as the javadoc says. 
> > So either the doc or the result is wrong.
> > 
> > 2) Please check the new log messages. The severity level warning
> > should not
> > be used for debug messages.
> > A warning message should be understandable for the end user.
> > 
> > 3) Reg. performance:
> > I think most of the area.intersect calls are not needed when you
> > add
> > this
> > block at the beginning of
> > splitIntoAreas():
> > 		// quick check if bbox of shape lies fully inside one
> > of the areas 
> > 		for (int areaIndex = 0; areaIndex < areas.length;
> > ++areaIndex) {
> > 			if
> > (areas[areaIndex].getBounds().contains(e.getBounds())) {
> > 				used[areaIndex] = true;
> > 				areas[areaIndex].addShape(e);
> > 				return;
> > 			}
> > 		}
> > 		// Shape crosses area(s), we have to split it
> > 		// Convert to a awt area
> >                ...
> > 
> > ciao,
> > Gerd
> > 
> > 
> > 
> > 
> > 
> > --
> > View this message in context: 
> > http://gis.19327.n8.nabble.com/patch-to
> > -write-polygons-in-decreasing-order-tp5884038p5885742.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
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sortAreas_v5.patch
Type: text/x-patch
Size: 27567 bytes
Desc: not available
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20161111/2bf9de69/attachment-0001.bin>