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

11 Nov 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@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev