Here is a patch for mapnik.txt that: - removes a "," from a default string. - doesn't indent the Bay Xpm section. - fixes a spelling mistake. The first 2 changes might stop errors when TYPViewer reads the file Ticker On Wed, 2020-03-25 at 08:56 -0700, AnkEric wrote:

Hi Ticker,

...

Line 1959 - is TYPViewer objecting to "String=River..." because it wants something of the form "String1=0x00,River..." or is it objecting to the "," between River & Wadi?

This is "acceptable" to TYPViewer: String=River Wadi (Intermittent) String1=0x01,Cours d’eau (intermittent)

So (...?) for "unspecified language" (default??) TYPViewer doesn't like csv.

Next TYPViewer will "renumber", so this was not the issue: String1=0x00,River Wadi (Intermittent) String2=0x01,Cours d’eau (intermittent)

...

Polygon 0x3d errors - Not sure what it doesn't like here

I don't know either, I just resolved "Quick and (very) Dirty" because I wanted a proof of concept for a "mapnik"-Map.

...

This polygon should be transparent

Oké, thanks. Now I have the challenge to use mkgmap to convert typ -files from .txt to .typ, find a "bay" (have I ever seen one in real life??) and hopefully I will understand "the long debate".

...

if TYPViewer doesn't allow you to save in the required char-set then this is a fundamental problem in using TYPViewer to do the conversion.

TYPViewer will Save utf8 As utf8 and Save 1252 As 1252. So the encoding of my source file is leading. So I have a work-around.

Eric (AnkEric)

-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

1. Open "mapnik.txt" in TYPViewer 2. Edit: Type=0x3d 3. Update Colors, Day and Night: from #000000 to #FFFFFF 4. Different Colors for Night = yes (!!!) 5. Different Colors for Night = NO (!!!) 6. Save 7. Done <http://gis.19327.n8.nabble.com/file/t344065/mapnik.png> Attached: "mapnik_FIX.txt" mapnik_FIX.txt <http://gis.19327.n8.nabble.com/file/t344065/mapnik_FIX.txt> Eric (AnkEric) -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

Hi Ticker, /> Is there a change that you'd like to see in the next version?/ No, thanks. Please consider: I'm only a private user. Therefore my RFC's or suggestions are only relevant if other users might benefit as well. My conclusion (FWIW): Use "mapnik_fix.txt", update with Comments (restore lost information), rename to "mapnik.txt" and save in mkgmap repository. Next version: verify "mkgmap.txt" to be compliant, compatible with TYPViewer. Yes, this would be a change I'd like to see in the next version! But first: verify if ([_polygon] type=0x3d, Bay) is okay for mkgmap if TYPViewer changes are applied. Anke does not know what (natural=bay) is, where to find it (it's not in the Netherlands) and how to verify if it's up to mkgmap standards. A [natural=bay] is on top of the water? Similarly to [leisure=marina]? And should be rendered by name only? OT? Yes and No, since the "bay" took me an hour of billable work yesterday. Moreover, Anke is wondering why [natural=bay] is explicitly rendered by mkgmap-default and (wetland=swamp) is not rendered by mkgmap-default. Disappointing to say the least. Or why (natural=wetland & name=*) and (natural=wetland & name!=*) are rendered differently? Hiding "wetland" as "meadow" if wetland is having a name? /> This is fine for your usage, but not for changing the file in the mkgmap repository./ IMO, mkgmap - as a Global Application, having Global Users - needs a very good reason for not being compliant. In this context being not compliant to TYPViewer. "Change typfile (easy using TYPViewer) is your first option if you don't like the OSM-Map" is a suggestion I have made very often to dissatisfied users. Also for me: If I should want to change mkgmap.txt it's most simple by updating mkgmap.txt by TYPViewer, without having to Resolve the one (!) remaining "Error" or "Syntax difference" ([_polygon] type=0x3d) first. /> The problem with using TYPViewer to change the file is that it has made lots of arbitary/irrelevant textual changes, lost information about the source encoding, added information about the destination encoding, removed the comments, etc/ Fact or fable? Yes, TYPViewer did "remove the comments" (if "mkgmap.txt" is converted to "<TYPViewer>.txt", but why would a user want to do this?). If comments are added to mkgmap.txt, a User can see the comments. Once a User or mkgmap will update "mkgmap.txt" to "mkgmap.typ" this information is lost, but also not required for Compiling the Map. All Compilers will always remove all comments in SourceCode. TYPViewer will generate a TXT file from the Compiled version (if requested), therefore Comments are removed, except for TYPViewer's own Comments. And since this - IMO - is the only drawback for TYPViewer: have we ever suggested this as a RFC to sherco40@ntymail.com ? Sherco has updated TYPViewer in my interest in the past. mkgmap.txt: [_id] /;ProductCode=1 set from --product-id ;FID=8094 set from --family-id ;CodePage=65001 set from --code-page/ If I Change this into the next lines, TYPViewer will respect that, therefore no "lost information about the source encoding": [_id] ProductCode=1 FID=8094 CodePage=65001 If I don't Set encoding (in "mapnik.txt"), I can set it inside TYPViewer: <http://gis.19327.n8.nabble.com/file/t344065/TYPViewer_Encoding.png> Encoding: TXT file mapnik is: "utf-8 BOM, Unix (Lf)" /; -*- coding: UTF-8 -*- NB: first 3 bytes/char in file is UTF-8 encoded ByteOrderMark (BOM)/ TXT file TYPViewer is: "utf-8, Win (CrLf)" *Fact checking:* Compare "mkgmap.txt" and "mkgmap_fix.txt " and look for "arbitrary/irrelevant textual changes". To do so, Professionally I use UltraEdit and UltraCompare. Privately I use EditPad Lite (free for personal use) and WinMerge (free software). Both highly recommended for OSM, mkgmap. <http://gis.19327.n8.nabble.com/file/t344065/TypeFiles_Compared_mkgmap_TYPViewer.png> 1. TYPViewer will remove Comments: ;Author: Jorisbo@hotmail.com ; ;Based on mkgmap default style version: r4293...4288 ; Etc. 2. TYPViewer will add more Comments: ;=========== POLYGONES : PRIORITE DANS L'AFFICHAGE ====== Unfortunately in French language, which is - imo - as "unwanted" as Dutch or German language, not to mention Chinese. 3. TYPViewer sets Case: "type" > "Type", "subtype" > "SubType" 4. TYPViewer will Sort [_drawOrder] (but will not change [_drawOrder]): Type=0x04b,1 Type=0x03d,1 Type=0x002,2 to: Type=0x03b,1 Type=0x04d,1 Type=0x002,2 5. TYPViewer will change Transparant: "." > " " 6. TYPViewer will sort and renumber Language: Mapnik: String=Village String1=0x01,Résidentiel String2=0x02,Wohngebiet String4=0x03,Bebouwing TYPViewer: String1=0x00,Village String2=0x01,Résidentiel String3=0x02,Wohngebiet String4=0x03,Bebouwing Thanks to TYPViewer sorting and renumbering Language Strings, it immediately stood out (looking at TYPViewer TXT file) translations are incomplete in mapnik.txt. Complete is: String1 - String8 (8 languages). Incomplete is: String1 - String7 (one language missing) String1 - String4 (four languages missing). Examples of missing languages: [_polygon] Type=0x05 ;GRMN_TYPE: Large Manmade Areas/PARKING_LOT/Parking lot area/Non NT String1=0x00,Parking Lot String2=0x01,Parking String3=0x02,Parkplatz String4=0x04,Car Park String5=0x03,Parkeerterrein String6=0x15,Parking String7=0x10,Estacionamento String8=0x05,Parcheggio ExtendedLabels=Y [_polygon] Type=0x07 ;GRMN_TYPE: Large Manmade Areas/AIRPORT/Airport area/Non NT String1=0x00,Airport String2=0x01,Aéroport String3=0x02,Flughafen String4=0x03,Vliegveld String5=0x15,Lotnisko String6=0x10,Aeroporto String7=0x05,Aerodromo ExtendedLabels=Y [_polygon] Type=0x12 ;GRMN_TYPE: // String1=0x00,Retail String2=0x01,Aire String3=0x02,Raststätte String4=0x03,Snelweg rustplaats ExtendedLabels=Y Eric (Eric & Anke, AnkEric) -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

Hi Ticker, This is exactly what I did experience last night: /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/ Although I admit: it was too late in the evening, had been watching Corona-tv and had a few drinks. What I did (don't ask me why...) is: 1. Open "mapnik.txt" in TYPViewer 2. Edit: Type=0x3d 3. Update Colors, Day and Night: from #000000 to #FFFFFF *4. Different Colors for Night = yes (!!!) 5. Different Colors for Night = NO (!!!)* 6. Save 7. Done This - the "toggle" - Resolved Error #9. My suggestion: Send me the complete - patched - "mapnik.txt" file and I have a seventh look. I will return it once it's okay for me (no Error #9 after "read back") and perhaps we are done then. We might even be happy. But no promises I will act tonight. Eric -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

Hi Eric see embedded Ticker On Thu, 2020-03-26 at 05:46 -0700, AnkEric wrote:

Hi Ticker,

/> Is there a change that you'd like to see in the next version?/

No, thanks. Please consider: I'm only a private user. Therefore my RFC's or suggestions are only relevant if other users might benefit as well.

My conclusion (FWIW): Use "mapnik_fix.txt", update with Comments (restore lost information), rename to "mapnik.txt" and save in mkgmap repository. Next version: verify "mkgmap.txt" to be compliant, compatible with TYPViewer. Yes, this would be a change I'd like to see in the next version!

But first: verify if ([_polygon] type=0x3d, Bay) is okay for mkgmap if TYPViewer changes are applied.

Bay needs to be transparent. Changing the characters use to represent the pixels works around the TYPViewer problem.

Anke does not know what (natural=bay) is, where to find it (it's not in the Netherlands)

my old NL map had this: 51.34878873825073/3.7353515625 [name=Slufter Kwade Hoek, natural=bay] and these two named bays still exist https://www.openstreetmap.org/relation/3123125 https://www.openstreetmap.org/relation/1305743

and how to verify if it's up to mkgmap standards. A [natural=bay] is on top of the water?

A bay area will often include islands, so it must not hide these and the islands shouldn't be cut-out from the bay with a multipolygon relation. The reason for the polygon is for naming the area so the default style should be changed so the rule only triggers if named.

Similarly to [leisure=marina]? And should be rendered by name only?

this is not in the default style at the moment, but could be added (even if unnamed - it is a visible feature)

OT? Yes and No, since the "bay" took me an hour of billable work yesterday.

?

Moreover, Anke is wondering why [natural=bay] is explicitly rendered by mkgmap-default and (wetland=swamp) is not rendered by mkgmap-default.

wetland=swamp should only occur in conjunction with natural=wetland, which is handled by the mkgmap-default. Many of the decisions about what is handled by mkgmap-default are based on the standard TYPs supported by a typical Garmin device

Disappointing to say the least. Or why (natural=wetland & name=*) and (natural=wetland & name!=*) are rendered differently?

mkgmap-default doesn't do this

Hiding "wetland" as "meadow" if wetland is having a name?

I don't understand what you mean. I don't see anything in mkgmap -default that relates to this

/> This is fine for your usage, but not for changing the file in the mkgmap repository./

IMO, mkgmap - as a Global Application, having Global Users - needs a very good reason for not being compliant. In this context being not compliant to TYPViewer. "Change typfile (easy using TYPViewer) is your first option if you don't like the OSM-Map" is a suggestion I have made very often to dissatisfied users.

It might be easy, but it changes the file in ways that may cause incorrect behaviour, and in a typical file that hasn't been maintained by TYPViewer, it might change every section. Another tool my behave in a similar manner and feel free re-write the file in a different way; then it would quickly become impossible to know what is significant for any required changes.

Also for me: If I should want to change mkgmap.txt it's most simple by updating mkgmap.txt by TYPViewer, without having to Resolve the one (!) remaining "Error" or "Syntax difference" ([_polygon] type=0x3d) first.

The line that caused the TYPViewer input error has been changed in mkgmap. The other line that exposes a problem in TYPViewer should be be applied soon. It is difficult to predict the problems that other .typ manipulation tools might have.

/> The problem with using TYPViewer to change the file is that it has made lots of arbitary/irrelevant textual changes, lost information about the source encoding, added information about the destination encoding, removed the comments, etc/

Fact or fable?

Look at the saved .txt file

Yes, TYPViewer did "remove the comments" (if "mkgmap.txt" is converted to "<TYPViewer>.txt", but why would a user want to do this?).

Because they want to use TYPViewer to make changed to the mkgmap resources/typ-files/*.txt

If comments are added to mkgmap.txt, a User can see the comments. Once a User or mkgmap will update "mkgmap.txt" to "mkgmap.typ" this information is lost, but also not required for Compiling the Map.

This is obvious

All Compilers will always remove all comments in SourceCode.

Which compiler removes comments from the source code? Almost all won't copy the comments into the object format.

TYPViewer will generate a TXT file from the Compiled version (if requested), therefore Comments are removed, except for TYPViewer's own Comments. And since this - IMO - is the only drawback for TYPViewer: have we ever suggested this as a RFC to sherco40@ntymail.com ? Sherco has updated TYPViewer in my interest in the past.

Do this if you want to. I use a text editor to maintain the .txt file and mkgmap to convert it and build it into the map.

mkgmap.txt:

[_id] /;ProductCode=1 set from --product-id ;FID=8094 set from --family-id ;CodePage=65001 set from --code-page/

If I Change this into the next lines, TYPViewer will respect that, therefore no "lost information about the source encoding": [_id] ProductCode=1 FID=8094 CodePage=65001

It loses the BOM and encoding comment at the beginning of the file.

If I don't Set encoding (in "mapnik.txt"), I can set it inside TYPViewer:

<http://gis.19327.n8.nabble.com/file/t344065/TYPViewer_Encoding.png>

Encoding: TXT file mapnik is: "utf-8 BOM, Unix (Lf)" /; -*- coding: UTF-8 -*- NB: first 3 bytes/char in file is UTF-8 encoded ByteOrderMark (BOM)/ TXT file TYPViewer is: "utf-8, Win (CrLf)"

TYPViewer actually uses this information when you open a file with the standard "Open .TXT file" and gets its internal representation correct.

*Fact checking:* Compare "mkgmap.txt" and "mkgmap_fix.txt " and look for "arbitrary/irrelevant textual changes". To do so, Professionally I use UltraEdit and UltraCompare. Privately I use EditPad Lite (free for personal use) and WinMerge (free software). Both highly recommended for OSM, mkgmap.

<http://gis.19327.n8.nabble.com/file/t344065/TypeFiles_Compared_mkgma p_TYPViewer.png>

This reports 869 differences when the only required changes were changing a comma and some indentation. It would take a while looking at this diff be sure of this.

1. TYPViewer will remove Comments: ;Author: Jorisbo@hotmail.com ; ;Based on mkgmap default style version: r4293...4288 ; Etc.

2. TYPViewer will add more Comments: ;=========== POLYGONES : PRIORITE DANS L'AFFICHAGE ====== Unfortunately in French language, which is - imo - as "unwanted" as Dutch or German language, not to mention Chinese.

3. TYPViewer sets Case: "type" > "Type", "subtype" > "SubType"

4. TYPViewer will Sort [_drawOrder] (but will not change [_drawOrder]): Type=0x04b,1 Type=0x03d,1 Type=0x002,2 to: Type=0x03b,1 Type=0x04d,1 Type=0x002,2

It will change 0xNN to 0x0NN

5. TYPViewer will change Transparant: "." > " "

6. TYPViewer will sort and renumber Language: Mapnik: String=Village String1=0x01,Résidentiel String2=0x02,Wohngebiet String4=0x03,Bebouwing TYPViewer: String1=0x00,Village String2=0x01,Résidentiel String3=0x02,Wohngebiet String4=0x03,Bebouwing

Thanks to TYPViewer sorting and renumbering Language Strings, it immediately stood out (looking at TYPViewer TXT file) translations are incomplete in mapnik.txt. Complete is: String1 - String8 (8 languages). Incomplete is: String1 - String7 (one language missing) String1 - String4 (four languages missing).

There are a lot of missing translations / many other languages.

Examples of missing languages:

[_polygon] Type=0x05 ;GRMN_TYPE: Large Manmade Areas/PARKING_LOT/Parking lot area/Non NT String1=0x00,Parking Lot String2=0x01,Parking String3=0x02,Parkplatz String4=0x04,Car Park String5=0x03,Parkeerterrein String6=0x15,Parking String7=0x10,Estacionamento String8=0x05,Parcheggio ExtendedLabels=Y

[_polygon] Type=0x07 ;GRMN_TYPE: Large Manmade Areas/AIRPORT/Airport area/Non NT String1=0x00,Airport String2=0x01,Aéroport String3=0x02,Flughafen String4=0x03,Vliegveld String5=0x15,Lotnisko String6=0x10,Aeroporto String7=0x05,Aerodromo ExtendedLabels=Y

[_polygon] Type=0x12 ;GRMN_TYPE: // String1=0x00,Retail String2=0x01,Aire String3=0x02,Raststätte String4=0x03,Snelweg rustplaats ExtendedLabels=Y

Some might not have been given because the default is adequate.

Eric (Eric & Anke, AnkEric)

-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev