May 2021 - mkgmap-dev - The mkgmap lists

Douglas Peucker Filter and short lines
by Ticker Berkin 24 May '21

24 May '21

Hi Gerd / anyone else Attempting to improve filtering by considering their optimal order, I got much worse results at very low resolutions. The excess was lots of 1-res-unit lines (these came from the coastlines of lots of small islands) These lines start off sufficiently large to make it through the sizeFilter. Running the DP filter next, if intermediate points are less than - -reduce-point-density (default 2.6) res-units from the line between first and last point, they are dropped. This can result in a single point if the first and last points are equal, or a line shorter than at least 2 of the sub-lines that no longer exist. I'm not sure of the best approach to deal with this. I considered inhibiting DP if the distance between start&end (either overall or for the internal sub-processing) is less than the error distance, but this is wrong for polygons or lines that loop back towards their starting point. Maybe the DP error size must be less than sizeFilter size; For lines this is MIN_LINE_SIZE = 1 and not configurable, For polygons it is --min-size-polygon (default 8) or --polygon-size-limits. Running RemoveObsoleteFilter before or after DP effects the final result. Considering the functions of the filters, I think RemoveObsolete should be before DP; DP shouldn't produce obsolete points and there is no point in DP considering obsolete points. Ticker

1 0

Commit r4735: improve Logging/ debugging : todegrees.patch
by svn commit 24 May '21

24 May '21

Version mkgmap-r4735 was committed by gerd on Mon, 24 May 2021 improve Logging/ debugging : todegrees.patch - change Coord.toString() to return the same as toDegreeString() instead of a pair of Garmin units - add method toGarminString() to get a string with Garmin units - deprecate toDegreeString() http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4735

1 0

improve sea/coastline rendering
by Gerd Petermann 22 May '21

22 May '21

Hi all, see item 15 in http://gis.19327.n8.nabble.com/default-style-lines-enhancements-tc5971280.h… This is one that I do understand and support. I think there are only few situations in which you want to render natural=coastline as line. The only one that I can think of is that you don't render natural=sea polygons. Is that realistic? Gerd

2 1

Change Coord.toString() to return degrees instead of map units
by Gerd Petermann 22 May '21

22 May '21

Hi devs, I think almost nobody needs the Garmin lat/lon coordinates in log or debug messages, the degrees are much easier to use. This is esp. true for debugging, so I want to change Coord.toString() to return the same result as Coord.toDegreeString(). The attached patch changes this and simplifies the code where possible. One unit test requires the garmin units, and the messages about boundary nodes in LineClipper are probably better understandable with garmin units. Unfortunately I have no easy way to find out where Coord.toString() is called implicitly when Object.ToString() is called, so maybe there are more places where .toGarminString() should be added. Any objections/hints/better ideas? The display tool uses toDegreesString(). I think it never uses Coord.toString() implicitly. Gerd

2 1

Line direction flag, merging etc
by Ticker Berkin 19 May '21

19 May '21

Hi Gerd and others I'm starting a dedicated thread as previous posts are split between various svn commits. Looking at the current trunk code and ignore-oneway-for-lines.patch, there are bits I don't understand or didn't expect. This is what I hope for: --line-types-with-direction lists the lineTypes for which the initial state of the hasDirection flag is considered true. It should be independent of --allow-reverse-merge (see later). The purpose of this is to reduce the need to edit styles and clarity as to which lineTypes are displayed with direction. In the following, road means line with [road_class, road_speed], so includes ferries. Style processing, having produced a line/road, sets hasDirection, in order of precedence: 1/ value of mkgmap:has-direction if tag exists 2/ true if oneway road 3/ true if in line-types-with-direction list RoadMerger merges roads with same lineType, names, class, speed, oneway and hasDirection. It must not reverse oneway or hasDirection=true roads when doing this. I don't think we need --allow-reverse-merge. LineMergeFilter operates for level > 0. It merges any line/road with the same lineType, names, hasDirection. It must not reverse hasDirection=true. Ticker

2 20

Commit r4726: modify evaluation of direction flag (again)
by svn commit 19 May '21

19 May '21

Version mkgmap-r4726 was committed by gerd on Wed, 19 May 2021 modify evaluation of direction flag (again) (dirFlagSetting_v2.patch by Ticker Berkin, modified) - don't ignore option --line-types-with-direction if --allow-reverse-merge option is not set - allow to have direction-flag unset even for ways with oneway=yes/-1 "The ambition was to be able to turn off hasDirection if [oneway=yes/-1] (roads only) and/or --lines-types-with-direction would have it on." http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4726

1 0

4179
by Felix Hartmann 18 May '21

18 May '21

Hi Gerd oneway tag no longer influences the direction flag of non-routable lines. Note that oneway=-1 still means line is reversed and oneway=yes is set. I think this is only needed if the linetype is listed under --line-types-with-direction If not listed here nor routable oneway=-1 is as irrelevant as oneway=yes I do not understand why we would have different handling of onway=yes and oneway=-1 Reversing the road should not be needed because it does not matter for the layout, nor for the routing. -- Felix Hartman - Openmtbmap.org & VeloMap.org

3 19

Different levels in Overview map
by Thomas Morgenstern 16 May '21

16 May '21

Hi, I noticed, that the linetyp highway=motorway is treated different in the overview map . For example the motorway A9 is Data1, motorway A73 is Data0 (I use GpsMapedit for analyse: polish map format). Polyline 0x01 : in Zoomlevel1 =6493 entrys, in Zoomlevel0=13676 entrys. Also polygon 0x27 : in Zoomlevel2=1519 entrys, in Zoomlevel0=20641 entrys. .Some entrys have Data2, others have Data0. Because that, when I zoom in or out, some motorways are displayed, others not displayed. I would expect, that same objects come to the same Level. I use my own STYLE. but is not very different from default. What can I do to avoid such inconsistence ? In my opinion, the same object should be completely contained at the same level. Thomas

2 1

Commit r4715: rework of options for reverse merge
by svn commit 16 May '21

16 May '21

Version mkgmap-r4715 was committed by gerd on Fri, 14 May 2021 rework of options for reverse merge - replace option --x-force-reverse-merge by --allow-reverse-merge which has to be set to enable reversing for merge, add documentation - implement new option --line-types-with-direction to list line types which should not be reversed, also documented - special tag mkgmap:has-direction=yes/1/true can be used to to mark a line as not reversable - special tag mkgmap:has-direction=no/0/false can be used to to mark a line as reversable (does not overwrite oneway=yes or oneway=-1 tag, only the --line-types-with-direction option) - remove code to detect if style sets mkgmap:has-direction=true - remove code to propagte the mkgmap:has-direction=true tag to underlying roads, might not be needed this reverts r4713 and r4714 and partly r4703 - don't merge lines with different has-direction flag (as r4710 in the low-res-opt branch) http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4715

5 22

Patches ignore oneway tag for non-routable lines
by Gerd Petermann 15 May '21

15 May '21

Hi all, following the discussion about commit r4715 here is a small patch to change mkgmap so that it doesn't set the direction flag in IMG when an OSM way has a oneway=1 or oneway=-1 tag when the corresponding line is not a road (a routable line with roadclass or road speed). Two patches because Ticker suggests to evaluate oneway also for lines and assume that the style will set mkgmap:has-direction=no to overwrite it. The other patch simply doesn't evaluate oneway for the direction flag. This gives smaller image files for styles which wee not yet changed. Gerd

2 1