- mkgmap-dev - The mkgmap lists

Commit r4477: mapnik-TYPViewer-3.patch by Ticker Berkin:
by svn commit 02 Apr '20

02 Apr '20

Version mkgmap-r4477 was committed by gerd on Thu, 02 Apr 2020 mapnik-TYPViewer-3.patch by Ticker Berkin: - mkgmap TYP compiler skips [_comments] ... [End] sections - for TYP lines in the [_id] section like: ProductCode= FID= CodePage= ie. without a value, mkgmap now writes a WARN message to the log instead of a SEVE: MapFailedException. These values will be supplied from the main mkgmap --options anyway. - put the mapnik.txt copyright message etc in the new [_comments] section - a few minor layout tweaks to mapnik.txt http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4477

1 0

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

Commit r4476: mapnik-TYPViewer-2.patch by Ticker Berkin:
by svn commit 01 Apr '20

01 Apr '20

Version mkgmap-r4476 was committed by gerd on Wed, 01 Apr 2020 mapnik-TYPViewer-2.patch by Ticker Berkin: I've changed the characters used to represent the pixels in the bay icon. I've just loaded TYPViewer and used it to convert latest mapnik.txt to mapnik.typ. It seemed quite happy to do this, but when using TYPViewer to read back the .typ file, it gives the errors: Error while reading polygon 0x03d/00 : Error #9 Description: Subscript out of range ... This patch stop this happening. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4476

1 0

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