
Could the admin_levels be made configurable in some way? There are considerable differences in the size of these areas between different countries. I am thinking particularly of the lower admin_level (5) which might be better set to 6 (or even 8) in the UK. Level 5 corresponds to "regions" which are basically only for statistics and some government stuff - not many people would know what region they are in (except they could probably guess because they are called things like "South East England"). Level 6 corresponds to Counties, and everyone uses them. //colin On 2015-05-21 17:00, Gerd Petermann wrote:
Hi Andrzej,
I tried using --boundary-tags=administrative for splitter, the amount of additional data depends on the size of the largest boundaries.
Attached is a small patch that changes splitter so that it keeps administrative boundaries complete when the admin_level is between 5 and 11 (including).
This doesn't add much data to the output files in comparison to --boundary-tags=administrative when splitting e.g. Brazil with --max-nodes=800000 and --output=o5m: a) r422 output size: ~ 359 M b) patched version : ~381 M c) unpatched r422 with --boundary-tags=administrative: 402 M
I've also tested the effect on mkgmap. As expected, version a) produces some wrong / duplicate POI, but I don't see them for b) or c). The throughput is nearly identical, and the final img size is also almost equal.
So, I think the patch is the best compromise.
Gerd
Date: Thu, 21 May 2015 12:56:43 +0200 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Duplicate cities
Hi Gerd,
Hmm, splitter keeps most mp-relations complete, we only exclude some boundary relations.
I see. But maybe potential increase wouldn't be that big, if you add boundaries?
Or maybe you can preserve only some levels of boundaries?
Or you can use boundary data form --bounds option?
Anyway, I prefer version 1 - keep complete relation, that could be useful for mkgmap.
-- Best regards, Andrzej _______________________________________________ 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 [1]
Links: ------ [1] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev