[mkgmap-dev] Duplicate cities

Thu May 21 17:44:32 BST 2015

Well, I am thinking that the whole of the boundary of Scotland for
example (level 5 is the region, level 4 is the nation - they are
coterminous) will add an enormous overhead to all the tiles in Scotland.
Maybe it isn't worth it, especially if you say it is complex to
implement. 

As an aside, what happens to tiles which are entirely enclosed by a
boundary, without there being a node within the tile? 

//colin 

On 2015-05-21 18:31, Gerd Petermann wrote: 

> Hi Colin,
> 
> what difference do you expect when you 
> are able to configure that value?
> I'd expect a few MB difference in the OSM file size
> and nearly no difference in mkgmap output,
> on the other hand it woud be another complicated
> option.
> 
> Gerd
> 
> -------------------------
> Date: Thu, 21 May 2015 18:25:12 +0200
> From: colin.smale at xs4all.nl
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Duplicate cities
> 
> 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 at poczta.onet.pl
>>> To: mkgmap-dev at 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 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 [1]
> 
> _______________________________________________ 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 [1]

Links:
------
[1] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20150521/2efee9b4/attachment.html>