logo separator

[mkgmap-dev] Documentation for the new Douglas-Peucker options in low-res-opt branch

From Felix Hartmann extremecarver at gmail.com on Mon Jun 14 22:10:10 BST 2021

I think polygons can be higher value except at level=0. In general I think
it is better to have a bit higher values for higher levels. However then
again lower for the overview map. However if the improve-overview filter
chain would apply in general - then values need to be much lower. There is
very aggressive filtering in comparison.

-x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:5.2,13:5.2
--x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6

Why do we need higher values for resolutions far zoomed out? Most garmin
GPS devices are pretty slow if zoomed out far - so heavily filter those
polygons/lines to get decent speed. PC/desktop are fast enough for even
complicated overview map - so that one should be optimized for best visual
quality. Some filtering is needed usually however else Asia continent map
or Europe continent map would break the img size limit.

This is what I am using now - and it works pretty well. Also the polygon
size limits I feel the following is way better than default. Tiny dots look
more like errors than help much:
--polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20,
17:20, 16:20, 15:20, 14:20, 13:25"

On Mon, 14 Jun 2021 at 23:32, Mike Baggaley <mike at tvage.co.uk> wrote:

> Hi Gerd,
>
> I think the original documentation for --reduce-point-density and
> --reduce-point-density-polygon could do with some improvement. It also
> seems
> bizarre to have a recommended value that is not the default. Is 2.6 the
> default if --reduce-point-density is specified without a value, or is it
> also the default if the option is not specified? Are the units metres? Is
> the distance the same no matter what resolution is used, or does the
> distance increase at lower resolution? If the former, wouldn't it be better
> to increase by a factor of 1.414 at successive resolutions? Would this be
> sufficient to not need to be able to specify individual values for
> resolutions?
>
> I'm not keen on having two very differently named options that basically
> achieve the same aim and suggest that it would be better to simply extend
> the existing --reduce-point-density options with
> --reduce-point-density=value|resolution:value[,...] or even better
> --reduce-point-density=value[,...] where the first value applies to the
> first used resolution and so on, with the last value being scaled for any
> further resolutions that have not had a value specified.
>
> Is there a reason why polygons need different values than lines? Shouldn't
> reduce-point-density-polygon default to the reduce-point-density value?
>
> I note that although the documentation belongs to the low-res-branch, it is
> showing up on the mkgmap command line web page.
>
> Regards,
> Mike
>
> -----Original Message-----
> From: Gerd Petermann [mailto:GPetermann_muenchen at hotmail.com]
> Sent: 14 June 2021 07:43
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: [mkgmap-dev] Documentation for the new Douglas-Peucker options in
> low-res-opt branch
>
> Hi all,
>
> I've now added documentation for these new options, see:
>
> https://www.mkgmap.org.uk/websvn/diff.php?repname=mkgmap&path=%2Fbranches%2F
> low-res-opt%2Fresources%2Fhelp%2Fen%2Foptions&rev=4775&peg=4775
> <https://www.mkgmap.org.uk/websvn/diff.php?repname=mkgmap&path=%2Fbranches%2Flow-res-opt%2Fresources%2Fhelp%2Fen%2Foptions&rev=4775&peg=4775>
>
> Is it clear enough?
> I think the recommend value --reduce-point-density-polygon=8 is far too
> high
> at low resolutions. Should this be changed?
>
> Together with the new --improve-overview option this branch version can
> produce much better results for the lower resolutions.
>
> Gerd
>
>
>
>
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>


-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20210615/022976e6/attachment.html>


More information about the mkgmap-dev mailing list