[mkgmap-dev] Duplicate cities

Fri May 22 09:21:57 BST 2015

 

Thanks Gerd 

On 2015-05-22 09:34, Gerd Petermann wrote: 

> Hi Colin,
> 
> it turned out that your concerns were okay,
> the differences in the UK are much higher,
> so I've implemented a new option wanted-admin-level.
> 
> See also post for splitter 423.
> 
> Gerd
> 
> -------------------------
> From: gpetermann_muenchen at hotmail.com
> To: mkgmap-dev at lists.mkgmap.org.uk
> Date: Thu, 21 May 2015 18:56:46 +0200
> Subject: Re: [mkgmap-dev] Duplicate cities
> 
> Hi Colin,
> 
> It would not be complicated to implement, but I fear the documentation.
> Today I've tested with Brazil, once with levels 4-11, once with 5-11.
> Size difference was only 10MB (sum for all 27 tiles), 
> so I don't expect a big change in the UK
> when you would use e.g. 6-11.
> 
> I'll think about a good option name and docu for it,
> if I find one I'll add it.
> Suggestions are wellcome.
> 
> Gerd
> 
> -------------------------
> Date: Thu, 21 May 2015 18:44:32 +0200
> From: colin.smale at xs4all.nl
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Duplicate cities
> 
> 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]

_______________________________________________ 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 

_______________________________________________
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/20150522/05955fd6/attachment.html>