Hi Felix,
yes, I have similar results.
I am playing with an implementation that first only merges lines in the given
direction and then tries again to merge with reversed order, but only if the
way has no specific direction. The img format has a flag for "has a direction",
and another one for "is oneway".
With the current code you can only use the oneway=* tag to tell mkgmap that a
way has a direction.
It turned out that it looks wrong to merge waterways with a direction, so I
added
(waterway=river | waterway=stream | waterway=rapids | waterway=waterfall) {add
oneway=yes}
I think a new tag mkgmap:has-direction=1" would be the better alternative.
A list of types would be another alternative, but I think the style is the
right place to do that (and much easier to implement and document)
Roads are handled earlier by the RoadMerger, and further merging is only
possible in the overview map where there is no NET file so far.
Now, most of the ways which are merged in reversed order are boundaries.
Probably because we have incomplete type=boundary relations and thus the
members of those relations are not joined to single closed ways. Looking at
this now, maybe it is better to use the joined way instead of the fragments.
Gerd
________________________________________
Von: mkgmap-dev <[email protected]> im Auftrag von Felix
Hartmann <[email protected]>
Gesendet: Mittwoch, 5. Mai 2021 03:47
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] new branch low-res-opt to test improvements for
filters
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
<[email protected]<mailto:[email protected]>> 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 a
ll.
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
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
--
Felix Hartman - Openmtbmap.org & VeloMap.org
--
Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________
mkgmap-dev mailing list
[email protected]
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
