- mkgmap-dev - The mkgmap lists

Commit r4256: Line pixmap width check, and unicode typ files
by svn commit 26 Nov '18

26 Nov '18

Version mkgmap-r4256 was committed by steve on Mon, 26 Nov 2018 Line pixmap width check, and unicode typ files http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4256

2 1

closed ways and multi-polygon relations
by Ticker Berkin 23 Nov '18

23 Nov '18

Hi Gerd I'd hoped and expected that all polygons were fed into the 'lines' style processing in a similar manner, regardless of their origin as either a closed OSM way or generated by multiPolygonRelation. This would allow simple testing using just 'is_closed()=true' to effect lines around polygons if required. Instead I find that, for a few examples I've looked at in detail, for each outer way in a relation a way is passed into 'lines'. They all have identical tags (from the relation) and is_closed()=false. It is difficult to determine if these correspond directly to the ways in the relation. In the generated map, the line around the area might be in multiple segments, so some logic appears to have merged some of the ways but not others. In my example is seems as if merging has been prevented when the original ways have conflicting tags (maybe just the name=) Given that it isn't possible to differentiate the multiple outer ways when passed in from multiPolygon, why doesn't it just pass in the joined way that will be passed to the 'polygons' processing. Also, assuming that later processing is joining some of these parts, what stops it joining them all. I can give you details of my example if required, but just having: mkgmap:mp_created=true & is_closed()=false {echotags 'mpNotClosed'} in 'lines' then looking for consecutive identical 'Way generated from...' output and checking that there is only 1 output polygon will yield a lot. Another difference between closed ways and multi-polygons is that with a closed way the object is passed through the rules of 'lines' concatenated with 'polygons' and all the facilties of stopping after a match/continue/with_actions work in a nice way, whereas with a multi -polygon, even if it matches in 'lines', it is passed through 'polygons' as well; so extra conditions will is needed in 'polygons' to determine if matched in 'lines' Regards Ticker

3 6

Re: [mkgmap-dev] Add a POI to the start of a relation (route:mtb)
by andreas.schmidt.hetschbach＠t-online.de 22 Nov '18

22 Nov '18

Hi Gerd, you got it. 1-2) I see these Problems also. But there are at least partial goals one could achieve even if the route is incomplete or not sorted: • One can search for MTB-Routes as POIs (taking into account that the POI could be shown SOMEwhere on the route) • Obtain all the data which is avaiable on OSM About the route (like ascent/distance, Operator, Website ) 3) At least the goals as in 1-2 will be reached, in addition mkgmap could check role = Forward/backward to be sure if the end or the beginning of the way is the first node. (if it is way). Andreas Gesendet von Mail für Windows 10

3 8

Add a POI to the start of a relation (route:mtb)
by andreas.schmidt.hetschbach＠t-online.de 21 Nov '18

21 Nov '18

Hi all, I would like to add something like a start-flag to mtb-routes containing all the Information of this relation available in OSM (like ascent, descent, distance). I tried addpoi2lines and restrict this to a special member of the relation (like role=start). This works, but the nodes aren`t tagged this way. Is there a chance to restrict the addpoi2lines to the FIRST member-node of the relation? This would - Restrict the creation of a POI to only one way of the relation - Restrict the creation to the start of the relation, assuming the relation is created in the Right order. Thx for any help, Andreas Gesendet von Mail für Windows 10

3 4

Maps no longer working after firmware upgrade?
by ael 18 Nov '18

18 Nov '18

I have just updated the firmware on my Etrex 20 to version 4.80. The OSM map no longer works. Very worrying. Obviously I need to provide far more detail, but is this a known problem? My contour map does still display, which is less worrying.

5 12

WG: AW: Add a POI to the start of a relation (route:mtb)
by andreas.schmidt.hetschbach＠t-online.de 18 Nov '18

18 Nov '18

1 0

Commit r4253: addr:place compare: don't just compare the pointers
by svn commit 16 Nov '18

16 Nov '18

Version mkgmap-r4253 was committed by gerd on Wed, 14 Nov 2018 addr:place compare: don't just compare the pointers http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4253

3 2

Commit r4255: commit change that is needed since 4252
by svn commit 16 Nov '18

16 Nov '18

Version mkgmap-r4255 was committed by gerd on Fri, 16 Nov 2018 commit change that is needed since 4252 http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4255

1 0

Commit r4254: defaultStyleTidy1.patch by Ticker Berkin
by svn commit 15 Nov '18

15 Nov '18

Version mkgmap-r4254 was committed by gerd on Thu, 15 Nov 2018 defaultStyleTidy1.patch by Ticker Berkin just reformatting, no functional change http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4254

1 0

Commit r4252: - compare also the addr:place name when looking for duplicate house numbers
by svn commit 14 Nov '18

14 Nov '18

Version mkgmap-r4252 was committed by gerd on Wed, 14 Nov 2018 - compare also the addr:place name when looking for duplicate house numbers - print a warning when a label that is needed for address search was not added to the labels because all 4 labels were filled. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4252

1 0