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

Fri Mar 27 17:23:15 GMT 2020

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

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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev