[mkgmap-dev] Errors converting "mapnik.txt" into "mapnik.typ" (information only)

Thu Mar 26 12:46:46 GMT 2020

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 at 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 at 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