[mkgmap-dev] new branch low-res-opt to test improvements for filters

Wed May 5 02:47:05 BST 2021

oh sorry, no I got confused. We don't need that difference based on level.
It's one list where we add all types that in the typfile lead to being
impossible to change direction and then of course any routable line can be
merged also at level 0 if it is not on that list and has no
oneway attribute. For level 1 and higher it is only about the list and
those types which could not be merged because of oneway attribute can now
also be merged.

On Wed, 5 May 2021 at 09:42, Felix Hartmann <extremecarver at gmail.com> wrote:

> I think the simplify 4 patch had some more improvements for contourlines -
> but then I played around all the time with the DP values so it's hard to
> compare. I do know that simplify v4  versus 3 back then was an improvement.
> I think merging lines of different directions would be good too - with the
> caveat that we would need an additional instruction in the lines style-file
> to tell for lines not to merge (maybe make this a list - because then it's
> not needed each occurrence in the lines file, but once per type. I feel
> this is only important for any type that is either off center (e.g. I have
> MTB routes on the right side of the center line, hiking routes on the left
> - so you can see both if on the same way) or that have an arrow or similar
> in the typ-file (i.e. I have arrows on my rivers so you can see the
> direction of water flow). Oh and not sure if this is would be merged also
> at level 0 or only >0. That would make a big difference in how many
> line types I put on that list. I mean there are many types also at level 0
> where I don't care about the direction. Of course any line with oneway that
> is routable could not be merged too. On the other hand even quite a few
> routable lines could be merged - but not all.
> If this also applies to level 0, then that file needs to have one command
> for level 0, and one command for level 1 and higher. At level 1 and onwards
> it only depends on the typfile if merging is possible or not. At level 0 it
> depends on both typfile and oneway attribute.
>
> On Mon, 3 May 2021 at 23:28, Gerd Petermann <
> GPetermann_muenchen at hotmail.com> wrote:
>
>> Hi all,
>>
>> as a result of the thread about raster problems I've started this new
>> branch.
>>
>> First commit implements experimental options to specify values for
>> --reducePointError and --reducePointErrorPolygon for each resolution
>> Options are --simplify-filter-line-errors as replacement for
>> --reducePointError and --simplify-filter-polygon-errors as replacement for
>> --reducePointErrorPolygon.
>> If --simplify-filter-line-errors is given and
>> ----simplify-filter-polygon-errors is not given the values for lines are
>> also used for polygons.
>> Meaning is similar to the --polygon-size-limits option, values are given
>> in pairs <resolution,reduce-value>
>> Note that in resolution 24 the filter is not used.
>> Sample usage:
>> --x-simplify-filter-line-errors=23:1.3,22:2.6,20:4,18:6
>> --x-simplify-filter-polygon-errors=23:1.3,22:2.6,20:4
>> The old options are still supported, --reducePointErrorPolygon=1.3 is
>> treated like --x-simplify-filter-line-errors=23:1.3
>>
>> If none of the options is used the default is 2.6 for all resolutions.
>>
>> There are a few more things to change:
>> - simplify4.patch with special code to improve rendering of contour lines
>> - more-merge.patch to allow merging of roads at level > 0
>> - Line merger could merge more lines if direction of the lines doesn't
>> matter
>> - maybe I find a way to merge dual-carriage ways into one line (again, if
>> direction doesn't matter)
>> - the --housenumber option should probably not assign numbers to trunk
>> roads (similar to motorways), this can add lables to these roads and thus
>> prohibit merging.
>>
>> None of these changes should change routing results. They can reduce img
>> size and improve rendering.
>>
>> 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
>
>

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