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

2020-04-01 Thread 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
Index: resources/typ-files/mapnik.txt
===
--- resources/typ-files/mapnik.txt	(revision 4476)
+++ resources/typ-files/mapnik.txt	(working copy)
@@ -1,28 +1,33 @@
 ; TYP file to give mapnik rendering
 ; -*- coding: UTF-8 -*- NB: first 3 bytes/char in file is UTF-8 encoded ByteOrderMark (BOM)
-;
-;This program is free software; you can redistribute it and/or modify
-;it under the terms of the GNU General Public License version 3 or
-;version 2 as published by the Free Software Foundation.
-;
-;This program is distributed in the hope that it will be useful, but
-;WITHOUT ANY WARRANTY; without even the implied warranty of
-;MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-;General Public License for more details.
-;
-;Author: jori...@hotmail.com
-;
-;Based on mkgmap default style version: r4293...4288
-;
+
+[_comments]
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License version 3 or
+version 2 as published by the Free Software Foundation.
+
+This program is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+Author: jori...@hotmail.com and others
+
+Based on mkgmap default style version: r4293
+[End]
+
+
 [_id]
 ;ProductCode=1   set from --product-id
 ;FID=8094set from --family-id
 ;CodePage=65001  set from --code-page
 [End]
-;
+
+
+;=== POLYGONS : RENDERING PRIORITY ==
 [_drawOrder]
+Type=0x03d,1
 Type=0x04b,1
-Type=0x03d,1
 Type=0x002,2
 Type=0x003,2
 Type=0x007,2
@@ -75,7 +80,11 @@
 Type=0x06c,8
 Type=0x004,9
 [End]
-;
+
+
+;= POLYGONS 
+
+
 [_polygon]
 type=0x02
 ;GRMN_TYPE: Urban Areas/SMALL_CITY/Small urban area, less than 200 000 inhabitants/Non NT
@@ -1184,7 +1193,11 @@
 Xpm="0 0 1 0"
 "1 c #BB"
 [end]
-;
+
+
+;== LINES ===
+
+
 [_line]
 type=0x01
 ;GRMN_TYPE: Roads/INTERSTATE, MAJOR_HWY/Primary, divided, limited-access highway, akin to an interstate in the US/Non NT, NT
@@ -2015,7 +2028,11 @@
 FontStyle=NoLabel (invisible)
 CustomColor=No
 [end]
-;
+
+
+;== POINTS ==
+
+
 [_point]
 type=0x001
 subtype=0x00
Index: src/uk/me/parabola/mkgmap/typ/IdSection.java
===
--- src/uk/me/parabola/mkgmap/typ/IdSection.java	(revision 4476)
+++ src/uk/me/parabola/mkgmap/typ/IdSection.java	(working copy)
@@ -13,6 +13,7 @@
 package uk.me.parabola.mkgmap.typ;
 
 import uk.me.parabola.imgfmt.app.typ.TypData;
+import uk.me.parabola.log.Logger;
 import uk.me.parabola.mkgmap.scan.SyntaxException;
 import uk.me.parabola.mkgmap.scan.TokenScanner;
 import uk.me.parabola.mkgmap.srt.SrtTextReader;
@@ -23,6 +24,8 @@
  * @author Steve Ratcliffe
  */
 class IdSection implements ProcessSection {
+	private static final Logger log = Logger.getLogger(IdSection.class);
+
 	private final TypData data;
 
 	public IdSection(TypData data) {
@@ -34,15 +37,25 @@
 		try {
 			ival = Integer.decode(value);
 		} catch (NumberFormatException e) {
-			throw new SyntaxException(scanner, "Bad integer " + value);
+			/* throw new SyntaxException(scanner, "Bad integer " + value);
+			 *
+			 * TYPViewer can leave these as:
+			 * FID=
+			 * ProductCode=
+			 * so just give a warning. Values will be supplied from mkgmap options.
+			 */
+			log.warn("bad/missing integer in TYP [_id] statement: ", name, "=", value);
+			ival = -1;
 		}
 
 		if (name.equalsIgnoreCase("FID")) {
-			data.setFamilyId(ival);
+			if (ival != -1)
+data.setFamilyId(ival);
 		} else if (name.equalsIgnoreCase("ProductCode")) {
-			data.setProductId(ival);
+			if (ival != -1)
+data.setProductId(ival);
 		} else if (name.equalsIgnoreCase("CodePage")) {
-			if (data.getSort() == null) // ignore if --code-page
+			if (ival != -1 && data.getSort() == null) // ignore if --code-page
 data.setSort(SrtTextReader.sortForCodepage(ival));
 		} else {
 			throw new SyntaxException(scanner, "Unrecognised keyword in id section: " + name);
Index: src/uk/me/parabola/mkgmap/typ/TypTextReader.java
===
--- src/uk/me/parabola/mkgmap/typ/TypTextReader.java	(revision 4476)
+++

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

2020-04-01 Thread 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
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

2020-04-01 Thread 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
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

2020-04-01 Thread 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  im Auftrag von Ticker 
Berkin 
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, eric_inter...@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)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

2020-03-31 Thread 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, eric_inter...@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)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

2020-03-27 Thread Ticker Berkin 
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
> ".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

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

2020-03-26 Thread 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 #00 to #FF
*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
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

2020-03-26 Thread 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
> ".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 sherc...@ntymail.com ? Sherco has updated
> TYPViewer in my interest in the past.
> 
> mkgmap.txt:
> 
> [_id]
> /;ProductCode=1   set from --product-id
> ;FID=8094set 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:
> 
>  
> 
> 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.
> 
>  p_TYPViewer.png> 
> 
> 1. TYPViewer will remove Comments:
> ;Author: jori...@hotmail.com
> ;
> ;Based on mkgmap default style version: r4293...4288
> ;
> Etc.
> 
> 2. TYPViewer will add more Comments:
> ;===

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

2020-03-26 Thread 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
".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 sherc...@ntymail.com ? Sherco has updated
TYPViewer in my interest in the past.

mkgmap.txt:

[_id]
/;ProductCode=1   set from --product-id
;FID=8094set 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:

 

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.


 

1. TYPViewer will remove Comments:
;Author: jori...@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

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

2020-03-25 Thread 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 #00 to #FF
> 4. Different Colors for Night = yes (!!!)
> 5. Different Colors for Night = NO (!!!)
> 6. Save
> 7. Done
> 
>  
> 
> 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
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

2020-03-25 Thread AnkEric 
1. Open "mapnik.txt" in TYPViewer
2. Edit: Type=0x3d
3. Update Colors, Day and Night: from #00 to #FF
4. Different Colors for Night = yes (!!!)
5. Different Colors for Night = NO (!!!)
6. Save
7. Done

 

Attached: "mapnik_FIX.txt"

mapnik_FIX.txt   

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

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

2020-03-25 Thread 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 #FF"
"  c none"
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
;12345678901234567890123456789012
[end]

Eric




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

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

2020-03-25 Thread 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
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devIndex: resources/typ-files/mapnik.txt
===
--- resources/typ-files/mapnik.txt	(revision 4474)
+++ resources/typ-files/mapnik.txt	(working copy)
@@ -768,41 +768,41 @@
 FontStyle=NoLabel (invisible)
 CustomColor=No
 Xpm="32 32 2 1"
-". c none"
-"1 c #FF"
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-;   "12345678901234567890123456789012"
+". c none"
+"1 c #FF"
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+;12345678901234567890123456789012
 [end]
 [_polygon]
 type=0x3f
@@ -1956,7 +1956,7 @@
 " !!  !!  !!  !!  !!  !!  !!  !! "
 " !!  !!  !!  !!  !!  !!  !!  !! "
 ;12345678901234567890123456789012
-String=River, Wadi (Intermittent)
+String=River/Wadi (Intermittent)
 String1=0x01,Cours d’eau (intermittent)
 String2=0x02,Fluß (Periodisch)

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

2020-03-25 Thread 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
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

2020-03-25 Thread 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 ".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
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev