Errors converting "mapnik.txt" into "mapnik.typ" (information only)

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Errors converting "mapnik.txt" into "mapnik.typ" (information only)

AnkEric
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
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Errors converting "mapnik.txt" into "mapnik.typ" (information only)

Ticker Berkin
Hi Eric

I use mkgmap to convert typ-files from .txt to .typ (just stick
mapnik.txt at the end of the parameter list, after the map data files)
It doesn't give these errors.

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?

Polygon 0x3d errors - Not sure what it doesn't like here, maybe the
indentation, as this is a significant thing different about it from,
say, 0x04. This polygon should be transparent - there was a long debate
about this at the beginning of the year. The only way to do this is
with a ICON.

From my experiments, Garmin devices expect the TYP section to be in the
same character-set as the map to which it is attached. Using mkgmap to
do the conversion handles this. mapnik.txt needs to be in some unicode
encoding as it encompasses many languages; 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.

Ticker

On Wed, 2020-03-25 at 07:38 -0700, AnkEric wrote:

> 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
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Errors converting "mapnik.txt" into "mapnik.typ" (information only)

AnkEric
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Errors converting "mapnik.txt" into "mapnik.typ" (information only)

Ticker Berkin
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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

mapnik-TYPViewer.patch (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Errors converting "mapnik.txt" into "mapnik.typ" (information only)

AnkEric
Almost but not quite... + ????

What I did:

Let mkgmap process: "mapnik.txt".
mkgmap will create: "mapnik.typ". So your suggestion is working ok!
Open "44010.typ" in TYPViewer. This is oké now.
If I want, I can Save "mapnik.typ" as "mapnik.txt".
Done!

But don't ask me about the differences between your patch and my "reverse
engineering".

TYPViewer will replace "." by " " and "1" by "!".
Oké give TYPViewer this as patch.
TYPViewer still not happy.
I am though...

This is what I see in TYPViewer:

ExtendedLabels=Y
FontStyle=NoLabel (invisible)
CustomColor=No
Xpm="32 32 2 1"
"! c #FFFFFF"
"  c none"
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
"                                "
;12345678901234567890123456789012
[end]

Eric




--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Errors converting "mapnik.txt" into "mapnik.typ" (information only)

AnkEric
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
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Errors converting "mapnik.txt" into "mapnik.typ" (information only)

Ticker Berkin
Hi Eric

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

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

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

Ticker

On Wed, 2020-03-25 at 15:41 -0700, AnkEric wrote:

> 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
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Errors converting "mapnik.txt" into "mapnik.typ" (information only)

AnkEric
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 [hidden email] ? 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: [hidden email]
;
;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
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Errors converting "mapnik.txt" into "mapnik.typ" (information only)

Ticker Berkin
Hi Eric / Gerd

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.

I also suspect TYPViewer character-set conversions. Looking at a
supposed 1251 .typ file, there were unicode characters in the strings.

I'll look the rest of your email later and respond.

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.
> 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 [hidden email] ? 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_mkgma
> p_TYPViewer.png>
>
> 1. TYPViewer will remove Comments:
> ;Author: [hidden email]
> ;
> ;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
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

mapnik-TYPViewer-2.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Errors converting "mapnik.txt" into "mapnik.typ" (information only)

AnkEric
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
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Errors converting "mapnik.txt" into "mapnik.typ" (information only)

Ticker Berkin
Hi Eric

Here is the full file patched according to my posting this afternoon.
I'd consider this behaviour a bug in TYPViewer.
You could have resolved the error #9 by opening the .txt file, saving
it as a .txt file and then opening the new file.

I don't want you to return to me anything that has been generated by
TYPViewer. If you need changes, just edit the file with a unicode
enabled text editor or tell me what you want changed.

Ticker

On Thu, 2020-03-26 at 12:07 -0700, AnkEric wrote:

> 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
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

mapnik.txt (171K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Errors converting "mapnik.txt" into "mapnik.typ" (information only)

Ticker Berkin
In reply to this post by AnkEric
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 [hidden email] ? 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: [hidden email]
> ;
> ;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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Errors converting "mapnik.txt" into "mapnik.typ" (information only)

Ticker Berkin
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, [hidden email] 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)
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Errors converting "mapnik.txt" into "mapnik.typ" (information only)

Gerd Petermann
Hi Ticker/Eric,

I didn't try to understand the issues. Please let me know if I should commit mapnik-TYPViewer-2.patch

Gerd

________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Dienstag, 31. März 2020 18:11
An: mkgmap development
Betreff: Re: [mkgmap-dev] Errors converting "mapnik.txt" into "mapnik.typ" (information only)

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, [hidden email] 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)
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Errors converting "mapnik.txt" into "mapnik.typ" (information only)

AnkEric
Hi Gerd,

This is not for me to decide. I'm just a User...

IMO: the mapnik-TYPViewer-2.patch is okay. So to be committed. IMO!

I will - again - verify (by TypViewer) if "mapnik.txt" is okay after
committed patch.
If not: I will let you know.

BTW: Did I gave you the impression I did understand???
ROFL...
I don't understand any of this, including my own document; -))

Eric





--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Errors converting "mapnik.txt" into "mapnik.typ" (information only)

Ticker Berkin
Hi Gerd

Yes, please commit.

I'm going to send another patch later for the mkgmap typ compiler and
it will include other changes to mapnik.txt so Eric, you might want to
hold off your testing until this is also committed.

Ticker
 
On Wed, 2020-04-01 at 01:35 -0700, AnkEric wrote:

> Hi Gerd,
>
> This is not for me to decide. I'm just a User...
>
> IMO: the mapnik-TYPViewer-2.patch is okay. So to be committed. IMO!
>
> I will - again - verify (by TypViewer) if "mapnik.txt" is okay after
> committed patch.
> If not: I will let you know.
>
> BTW: Did I gave you the impression I did understand???
> ROFL...
> I don't understand any of this, including my own document; -))
>
> Eric
>
>
>
>
>
> --
> Sent from:
> http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Errors converting "mapnik.txt" into "mapnik.typ" (information only)

Ticker Berkin
Hi Gerd, Eric

Here is another patch to help TYPViewer users

- 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] secti
on

- a few minor layout tweaks to mapnik.txt

Ticker

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

mapnik-TYPViewer-3.patch (7K) Download Attachment