Hi,
I tried to read all the docs and forums about max-nodes, but I still
have questions left:
* Does the splitter print an error when max-nodes is too large, or is
it unpredictable and will it only fail on the GPS device
* Do tiles with more nodes mean higher or lower draw performance on
Hi Ticker,
Ticker Berkin wrote
> 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
Version mkgmap-r3702 was committed by gerd on Fri, 11 Nov 2016
sortAreas_v5.patch: Add option --order-by-decreasing-area
Patch by Ticker Berkin, slightly modifed
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=3702
___
mkgmap-dev mailing
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
Hi Teemu,
Maybe I have a fix for this. We have special code in mkgmap for
POI with type >= 0x0100 && type <= 0x1100, they are considered to be cities
and those are special.
With the attached patch only those with subtype = 0 are:
type >= 0x0100 && type <= 0x1100 && (type & 0xff) == 0
This seems
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
