March 2020 - mkgmap-dev - The mkgmap lists

mapnik typ file and barrier=wall
by Gerd Petermann 29 Jun '20

29 Jun '20

Hi TYP experts, it seems that line type 0x17 (barrier=wall) is not visible in Basecamp? Gerd

6 8

Re: [mkgmap-dev] Errors converting "mapnik.txt" into "mapnik.typ" (information only)
by Ticker Berkin 01 Apr '20

01 Apr '20

Hi Eric There is a lot here! I don't want to spend a lot of time going through it point by point here are some comments and some changes, helpful to TYPViewer users, that could be made to mapnik.txt and mkgmap. 1/ DONE: remove a comma from a STRING default line. This is because mkgmap and TYPViewer use different parsing methods for: String[#]=[lang#,]description where [] indicates optional. mkgmap spots there is no language# 2/ PATCH in progress: Change a character used to represent a pixel colour. These characters are arbitrary, but something, either the . or the 1, causes TYPViewer to write an incorrect .typ file 3/ pixel characters can be chosen by the user; it is NOT an error to use different characters per icon. TYPViewer changes them to the characters it would use if it was reading a binary .typ file. 4/ Implement the [_comments] ... [end] section in mkgmap. These comments wouldn't put it into the .typ file unlike TYPViewer, which does. It is good for copyright and version information but not actual comments. Having experimented with this I find that TYPViewer is inconsistent when reading it back and sometimes reports a different header length and doesn't pick up the comments. 5/ What I meant by "supposed Win 1252 Typ file" is that it is very easy to get TYPViewer to generate a file where the Typ header says the CodePage is 1252, but the strings are encoded as utf8 hence chars>127 will show incorrectly. I was going try list some of the ways to get it correct and some that get it wrong, but there are many variables that might have an effect on this I'm finding this a time-consuming and pointless process. 6/ BOM and coding line. These lines are there so that there is a higher chance of tools (editors, compilers...) getting the source coding correct. Without these lines, some tools will scan the complete file checking that all chars >127 are part of a valid utf-8 sequence, some will just make assumptions and possibly get it wrong. 7/ TYPViewer recognises strings in mapnik.txt as being encoded as utf8 regardless of the method used to open the file or BOM/coding line (good - see above). On forcing a change to be saved, it converts to the specified CodePage, quietly mapping chars not in this CodePage to their more generic form. 8/ mkgmap TypCompiler does check for BOM. Up until January 2020, just in the utf8 encoding, but since then in 16LE/16BE/32LE/32BE as well, also looking for "-*- coding:" near the start of the file. 9/ Change mkgmap so that the message severity for missing numbers is downgraded for: ProductCode= FID= as these will be generated from other sources 10/ as per your recent mail, TYPViewer does change the Type hex numbers in the _draworder section 11/ utf8 should be the standard for all source files. You suggest it is not needed for 99% of usage, but you are ruling out most countries of the world. There is little extra effort required to support utf8 until we meet tools like TYPViewer. 12/ "Correct procedure" - most of this is fine for you, but I'd suggest always using TYPViewer in utf8/65001 mode and never using it to generate the .typ file. Then in mkgmap, use your normal --code -page=1252 because 65001 makes the map bigger and isn't supported on many Garmin devices. 13/ Actual translations in mapnik.txt: this is an ongoing effort by anyone who wants to improve it. In the spreadsheet you've highlighted quite a few default strings - I don't see what is wrong with them; they were specified as described in the posting: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030254.html You've also highlighted quite Dutch ones - could you do a patch for these based on either the file I sent you or the latest svn source file, or, failing that, just edit it and and sent it back to me. Best wishes - hope everyone is healthy Ticker On Mon, 2020-03-30 at 21:59 +0200, eric_internet(a)casema.nl wrote: > Hi Ticker, Gerd, > > I have spent "some" time in investigating "mapnik.txt" vs. > "TypViewer". > Understatement... > > Things got out of hand... > > Therefore: two attachments... > > Best regards, > > Eric (AnkEric)

3 4

Errors converting "mapnik.txt" into "mapnik.typ" (information only)
by AnkEric 27 Mar '20

27 Mar '20

mapnik.txt (128.746 bytes, 19-03-2020 08:31) I assume (...) "mapnik.txt" is to be converted into "<nnnnn>.typ". Using TYPViewer 4.5.50 two Errors during conversion: ******************************************************************** Errors in the file : mapnik.txt ******************************************************************** Line 1959 : "String=River, Wadi (Intermittent)" To Resolve, update: String=River, Wadi (Intermittent) into: String1=0x00,River (Intermittent) String2=0x01,Cours d’eau (intermittent) etc. ******************************************************************** Errors in the file : 44010.typ ******************************************************************** Error while reading polygon 0x03d/00 : Error #9 Description: Subscript out of range Error while reading polygon 0x03d/00 : Error #9 Description: Subscript out of range Error while reading polygon 0x03d/00 : Error #9 Description: Subscript out of range Error in the length of the polygon Type=0x03d SubType=0x00 Problem with the polygon Type=0x03d SubType=0x00 To Resolve: copy from Type=0x3c [_polygon] Type=0x3d ;GRMN_TYPE: Water Areas/LAKE_30MI, LARGE_LAKE/Large lake, typically between 30 and 500 sq mi in area/Non NT String1=0x00,Bay String2=0x01,Baie String3=0x02,Bucht String4=0x03,Baai String5=0x15,Zatoka String6=0x10,Baia String7=0x05,Baia ExtendedLabels=Y FontStyle=SmallFont CustomColor=Day DaycustomColor:#4D80B3 Xpm="0 0 1 0" "1 c #AAD3DF" [end] Also be aware: mapnik.txt is [UTF-8] encoding I assume (...) Garmin expects [Windows 1252] encoding. If [Windows 1252] is required, in TYPViewer "Open a TXT (Utf8) file...". Converted TYP file will have same encoding. -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

2 11

Commit r4475: improvements for typ file source mapnik.txt
by svn commit 26 Mar '20

26 Mar '20

Version mkgmap-r4475 was committed by gerd on Thu, 26 Mar 2020 improvements for typ file source mapnik.txt - removes a "," from a default string. - doesn't indent the Bay Xpm section. - fixes a spelling mistake. Patch by Ticker Berkin http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4475

1 0

Question (only): Is mkgmap-default-style Routing by foot/bicycle according to Usecase ?
by AnkEric 25 Mar '20

25 Mar '20

Is mkgmap-default-style Routing by foot/bicycle according to Usecase? 1. Navigate from "_START" to "_FINISH". Routing is OK for both foot and bicycle. Routing will not use the Motorway. <http://gis.19327.n8.nabble.com/file/t344065/1_Routing_Foot_Bicycle_Start_Fi…> 2. Add one Viapoint "_VIA" AND put it ON the Motorway. My deliberate Error is just for "testing" purposes. Although I have made the same mistake in real life several times. Foot and Cycling are very much prohibited on the Motorway. Now Routing will follow the Motorway. Which is an error, dangerous and an offence. <http://gis.19327.n8.nabble.com/file/t344065/2_Routing_Foot_Bicycle_Start_VI…> 3. My "own" Map is specific to Car or Bicycle or Foot only. My Bicycle_Map (or Foot_Map) will avoid the "_VIA" as much as possible. Simply refuses to use the motorway because of explicit [bicycle=no]. <http://gis.19327.n8.nabble.com/file/t344065/3_Routing_Foot_Bicycle_Start_VI…> Just a "proof of concept" question! I'm considering to migrate for my Car-map to mkgmap-default-style. Car only, so incorrect routing for foot/bicycle is no issue. For me... Eric (AnkEric) -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

2 4

Commit r4470: genSea.patch by Ticker Berkin
by svn commit 23 Mar '20

23 Mar '20

Version mkgmap-r4470 was committed by gerd on Wed, 18 Mar 2020 genSea.patch by Ticker Berkin fixes flooded areas caused by changes in r4392 and other issues with unclosed coastlines http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4470

4 15

Commit r4474: implement support for --copyright-file and --copyright-message option in PolishReader.
by svn commit 23 Mar '20

23 Mar '20

Version mkgmap-r4474 was committed by gerd on Mon, 23 Mar 2020 implement support for --copyright-file and --copyright-message option in PolishReader. (mp-copyright.patch) http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4474

1 0

Processing of mp source
by Andrzej Popowski 22 Mar '20

22 Mar '20

Hi, I'm curious, what processing is active, when source data is in mp format. Particularly, which mkgmap options are active? For example, do these options have any use: no-lower-case reduce-point-density reduce-point-density-polygon merge-lines min-size-polygon polygon-size-limits drive-on=detect order-by-decreasing-area preserve-element-order I have noticed, that --copyright-file option doesn't work, is it a bug? Maybe copyright form mp file could be used instead? -- Best regards, Andrzej

3 8

Question (RFC): Is function [has-period-ended] an option?
by AnkEric 21 Mar '20

21 Mar '20

Way/Area closure Period (from date_start until date_end) is – in general – not on OSM. Some exceptions: opening_hours = Mar 15-Jun 15 off "bird breeding season" Construction period is between two dates. Or: opening_hours = 2019 Feb 18-2019 Mar 29 closed "Reconstruction period Defensie Eiland" Or: access:conditional = no @ (2019 Feb 18-2019 Mar 29) For me it's hard to not forget to remove by the end of construction period. Therefore I Set: fixme = opening_hours to be deleted by 2019 Mar 21 Still, hard to not forget. Question: Can mkgmap implement a new function? [period-has-ended] Function: - Is there a date ("yyyy mmm dd") in opening_hours? Including "yyyy"? - If yes, find the last date. - If Today > Last_date Then [has-period-ended] = True Even better: Function has-period-ended (MyDate). Opening_hours (closure) will have ended (or not) after Map production date or start of my holiday: MyDate. I guess mkgmap Logging option (-Dlog.config=filename) can be used to generate a text file having all my Errors. I do hope { echotags "Error message... " } can be logged as well. Or I could Render outdated Warnings on the Map, differently from actual Warnings. And if this is an option, has mkgmap a preference for [opening_hours] or [access:conditional]? access:conditional is more straight forward, easier to interpret. But opening_hours has the option to add free text: "Reconstruction period Defensie Eiland", "ferry during working hours" (extra information and explanation). -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

2 3

One object has more than one POI-tag (Hotel Café Restaurant)
by AnkEric 20 Mar '20

20 Mar '20

Issue: One object has (or should have) more than one POI-tags. Possible situations: * "Hotel Restaurant Xxxx" * "Hotel Café Restaurant Xxxx" * "Café Restaurant Xxxx" * "Hotel Aaaa" and "Restaurant Aaaa" and "Café Aaaa" (same location, same operator, name "Aaaa" is identical for all Objects, but only one Node on OSM). OSM best practice and OSM worst practice: Relation: [type=site] + (building + hotel + restaurant + pub) as members. But, issues, options: * Address is on one node only. Duplicated addresses are error (imo), since an address is (should be) unique. * Name is set on relation only. But now I (as Renderer) cannot Get the name from the relation and Set it to the individual POI’s. Also Validators will complain: "this is a restaurant therefore a name is required". * Name is set on all individual POI-nodes. Which is redundant and (imo) therefore an Error. Hotel + name is tagged on building outline ([building=hotel] + [tourism=hotel] + [name=Hotel Aaaa]). Also (imo) not correct: POI-tags should be set on Address-POI-node. I sometimes search for a POI, look for the address and navigate there without using GPS. Also (some?) Renderers will not render POI-tags on building outline (JOSM). No idea how mkgmap (default) style will handle this. For me [mkgmap:line2poi] does resolve. One POI-node: [tourism=hotel] + [amenity=restaurant]. No option to also Add [amenity=pub] (conflicting tag). Renderer has to decide which POI will be rendered. One POI-node One tag ONLY: OR [tourism=hotel] OR [amenity=restaurant] OR [amenity=pub] OR [amenity=café]. Loss of information! On OSM last Mapper will decide ( <cynical-mode> ): "I use this hotel only as restaurant, therefore: Delete [tourism=hotel] + Set [amenity=restaurant]". As a result: we cannot find our hotel on OSM (except - sometimes - by name). Question (1): Is it possible (for me as Renderer) to Get Name by site_relation? Is it possible to Get address for all POI’s from the one Member having address set? (Although not sure if this would be good practice, since Renderer will now create Duplicated addresses). I suggest (for now) a short answers should be either: "Yes, you can: Read the Manual!", or: "Yes, you can: look at mkgmap default style for an example!", or: "No!". Question(2): If "One POI-node: [tourism=hotel] + [amenity=restaurant]" can mkgmap "DUPLICATE" a Node, so I can Render two POI’s: [hotel] + [restaurant]??? I do believe OsmAnd can do this. For a "DOUBLE-TAGGED-POI" I can search in TWO different Categories: "Accommodation" and "Café and restaurant". But also: OsmAnd can search for an address (by looking at near be addresses). This is no option for Garmin GPS. It might be even better (but I know: hard to implement) if I could Render TWO POI's on slightly different locations (top and below): - (hotel) "Hotel Aaaa" - (restaurant) "Restaurant Aaaa" OsmAnd will Render both POI’s on same location (but also: OsmAnd has an option to show "Accommodation" and/or "Café and restaurant"). -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

2 3