Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with default style (and other styles)

2020-06-29 Thread Joris Bo 
Hi Steve

I just tested the newly compiled jar and the pink line is there again!
Also routing in Demo-mode works on my Oregon 650.
Used bike, foot and car with default-style of recent April 2020 and the test 
area in Madrid that Felix pointed out.

I also tested it with my own style which uses the recent  
is_in(highway,pedestrian, any), is_drive_on_left() and nearby poi config 
feature.
No building errors and routing in basecamp for foot, car, bike and 
bike-through-ferry, car-avoid-bollard all seems ok 

Thx a lot, the service is amazing.


Kind regards,
Joris




-Oorspronkelijk bericht-
Van: mkgmap-dev  Namens Steve Ratcliffe
Verzonden: maandag 29 juni 2020 23:50
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with default 
style (and other styles)


Hi

 > Update, previous version had some errors, conclusion is the same

OK, Thanks that is great.

So I don't think that there wasn't really intended to be a change to routing in 
that branch, but there was an experimental option that was added, and then 
removed, with a couple of lines of code omitted, probably unintentionally.  
This is what causes the failure in NodCheck and maybe causes the failure on the 
device too.

The attached patch restores the functionality and NodCheck does not crash on 
the result

There is a pre-compiled jar there: 
http://files.mkgmap.org.uk/download/484/mkgmap.jar

It may interact or interfere with the routing island removal code that was also 
made in that branch.  I've no idea if it does or not, it is just something to 
check.

Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with default style (and other styles)

2020-06-29 Thread Steve Ratcliffe 


Hi

> Update, previous version had some errors, conclusion is the same

OK, Thanks that is great.

So I don't think that there wasn't really intended to be a change to
routing in that branch, but there was an experimental option that was
added, and then removed, with a couple of lines of code omitted,
probably unintentionally.  This is what causes the failure in NodCheck
and maybe causes the failure on the device too.

The attached patch restores the functionality and NodCheck does not
crash on the result

There is a pre-compiled jar there: 
http://files.mkgmap.org.uk/download/484/mkgmap.jar


It may interact or interfere with the routing island removal code that
was also made in that branch.  I've no idea if it does or not, it is
just something to check.

Steve
Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
===
diff --git a/trunk/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/trunk/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
--- a/trunk/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java	(revision 4555)
+++ b/trunk/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java	(working copy)
@@ -1499,6 +1499,13 @@
 	 */
 	private void addRoadAfterSplittingLoops(ConvertedWay cw) {
 		Way way = cw.getWay();
+		
+		if (routable) {
+			// make sure the way has nodes at each end
+			way.getPoints().get(0).incHighwayCount();
+			way.getPoints().get(way.getPoints().size() - 1).incHighwayCount();
+		}
+
 		// check if the way is a loop or intersects with itself
 
 		boolean wayWasSplit = true; // aka rescan required
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] CodePage number set to 0 after compiled

2020-06-29 Thread Mike Baggaley 
I suspect that the –latin1 option does not apply to the style compilation 
because the input file precedes the code page option.  In general options only 
apply to input files that are placed after the option (with a few exceptions). 
Try moving your type file to after –c template.args.
 
Cheers,
Mike
 
 
From: DD8KQ [mailto:dd...@gmx.de] 
Sent: 29 June 2020 13:40
To: Joris Bo ; Development list for mkgmap 

Subject: Re: [mkgmap-dev] CodePage number set to 0 after compiled
 
Hi Joris, 
since the beginning of building my own maps for my device i allways added this 
option to my map building command, at least to have the correct mapid in the 
typ-file. Here is one example, how i do this :
java -Xmx3m -XX:-UseGCOverheadLimit -ea -jar 
-Dlog.config=logging.properties "c:\Program Files 
(x86)\KartenTools\mkgmap\mkgmap.jar" --location-autofill=is_in,nearest 
--mapname=70030001 --family-id=7003 .\styles\newstyle.txt 
--series-name="GERMANY TEST" --family-name="OpenStreetmap" 
--country-name=GERMANYTEST --country-abbr=GER --area-name=GER 
--overview-mapname="overview" --latin1 --style-file=.\styles --style=newstyle 
--max-jobs --keep-going --check-roundabouts --drive-on=detect,right 
--output-dir=.\out\MYGERMANY --index --bounds=.\bounds_latest --route 
--name-tag-list=name,place_name,loc_name --housenumbers --split-name-index 
--add-pois-to-areas --link-pois-to-ways --process-destination --process-exits 
--precomp-sea=.\sea_latest  --tdbfile --draw-priority=10 --gmapsupp -c 
.\data\MYGERMANY\template.args --description=MYGERMANY 
--remove-ovm-work-files=true 
I opened this thread only to get an idea how to get rid of the TYPviewer error 
;-)
Am 29.06.2020 um 14:34 schrieb Joris Bo:
Hi Manfred,
 
I was not aware of Tickers tip that it was possible to supply a .txt in the 
same command line as the map building cmd. But it does make sense 😊
Always thought this must be a .typ and since the map building scripts only 
change when something gets broken I first noticed this a couple of month 
ago..
So I always first call mkgmap to create the .typ with correct codepage and 
family id and immediately after this, a second call to supply this newly  
created .typ to the map build call. At least this works for me.
 
Kind regards,
Joris
 
 
 
-Oorspronkelijk bericht-
Van: mkgmap-dev   
 Namens DD8KQ
Verzonden: maandag 29 juni 2020 13:16
Aan: mkgmap-dev@lists.mkgmap.org.uk  
Onderwerp: Re: [mkgmap-dev] CodePage number set to 0 after compiled
 
Hi all, i do not compile the typ.txt file as own process, its integrated in my 
command line for building my maps. But every now and then, i just open the 
resulting .typ-file with the viewer and since some time i saw these complaining 
errors. In my build options to create the map i'm using the option --latin1, as 
Joris suggested. But nevertheless, opening the typ file with TYPviewer i get 
allways this error.
 
Am 29.06.2020 um 12:47 schrieb Ticker Berkin:
> Hi Manfred
> 
> Generally it is better to supply the TYP .txt file as an argument to 
> mkgmap when you build your map, rather than compiling it as a separate 
> process.
> 
> Otherwise, as Joris says.
> 
> Do you have a codePage specified in the file that is being ignored?
> [_id]
> ...
> CodePage=
> ...
> [End]
> 
> Ticker
> 
> On Mon, 2020-06-29 at 10:39 +, Joris Bo wrote:
>> Hi Manfed,
>> 
>> I encountered the same, since  you must always supply the 
>> codepage on the commandline
>> 
>> Like
>> 
>> --code-page=65001
>> Or
>> --code-page=latin1
>> 
>> 
>> Joris
>> 
>> 
>> -Oorspronkelijk bericht-
>> Van: mkgmap-dev <  
>> mkgmap-dev-boun...@lists.mkgmap.org.uk> Namens 
>> Manfred Haiduk
>> Verzonden: maandag 29 juni 2020 12:29
>> Aan: Development list for mkgmap <  
>> mkgmap-dev@lists.mkgmap.org.uk>
>> Onderwerp: [mkgmap-dev] CodePage number set to 0 after compiled
>> 
>> Hi all,
>> 
>> i don't know, if i had something forgotten but since some time, if i 
>> compile my style.txt with mkgmap, the resulting typ-file seems to not 
>> have any codepage number other than Zero. Only the TYPviewer 
>> complains about this, on my device (GPSMAP 476cx) or with MapSource i 
>> don't see any troubles. This is the error message the TYPviewer 
>> generates :
>> 
>> *
>> *
>> 
>> Errors in the file  : D:\GPS\Maps\MYGERMANY\newstyle.typ
>> *
>> *
>> 
>> 
>> 
>> Unknown CodePage number: 0
>> TYPViewer has replaced it with 1252
>> If it doesn't fit, select an another CodePage number in the combobox 
>> "CodePage"
>> 
>> 
>> Any ideas what to do ?
>>

Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with default style (and other styles)

2020-06-29 Thread Felix Hartmann 
so I guess it would be good if we could have a current mkgmap without the
NOD patches - or without the img patches of 4360 - and see which one causes
the problem - and revert it. Those problems are really pretty common now.

On Mon, 29 Jun 2020 at 11:18, Joris Bo  wrote:

> Update, previous version had some errors, conclusion is the same
>
>
>
> *Build date*
>
> *Mkgmap*
>
> *Device*
>
> *Style*
>
> *Pink line*
>
> *Crash/Deadloop*
>
> *Result*
>
> *Comment*
>
> 24-8-2017
>
> r3995
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> Yes
>
> No
>
> Ok
>
> r4195
>
> Felix Hartmann
>
> Felix Personal
>
> ?
>
> Wrong
>
> Felix thinks he uses this version and his own style but is not sure
>
> 16-4-2019
>
> r4286
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> Yes
>
> No
>
> Ok
>
> 26-10-2019
>
> r4323
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> Yes
>
> No
>
> Ok
>
>
>
> r4358
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> Yes
>
> No
>
> Ok
>
>
>
>
>
> *r4359*
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> Yes
>
> No
>
> Ok
>
>
>
>
>
> *r4360*
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> No
>
> Yes
>
> Wrong
>
> This is what Ticker suspected and also Steve suggested. 4360 introduced
> new routing behaviour by design
>
>
>
> r4361
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> No
>
> Yes
>
> Wrong
>
>
>
>
>
> r4372
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> No
>
> Yes
>
> Wrong
>
>
>
> 17-11-2019
>
> r4373
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> Yes
>
> No
>
> Ok
>
> Orginally tested with jar file supplied by Jan Meisters: Thought it was
> oke!, still have the working img, but I cannot prove again this img was
> really created by that version. The Jar version of Steve creates an img
> that is not oke? 2nd & 3th time compile again with Jan's jar file to double
> check also suddenly is wrong: So I must have made a mistake in copy/paste
> or documenting the testresults. Conclusion 4373 is not oke
>
> 17-11-2019
>
> r4373
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> No
>
> Yes
>
> Wrong
>
> r4374
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> No
>
> Yes
>
> Wrong
>
> r4376
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> No
>
> Yes
>
> Wrong
>
> r4379
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> No
>
> Yes
>
> Wrong
>
> 6-12-2019
>
> r4384
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> No
>
> Yes
>
> Wrong
>
> 8-12-2019
>
> r4386
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> No
>
> Yes
>
> Wrong
>
> 25-1-2020
>
> r4431
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> No
>
> ?
>
> Wrong
>
> r4479
>
> Jan Meisters
>
> Oregon 450
>
> Jan Personal
>
> No
>
> No
>
> Half
>
> 19-6-2020
>
> r4551
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> No
>
> Yes
>
> Wrong
>
> 19-6-2020
>
> r4551
>
> Joris Bo
>
> Oregon 650
>
> Joris Personal
>
> No
>
> No
>
> Half
>
>
>
>
>
>
>
> *Van:* mkgmap-dev  *Namens *Joris
> Bo
> *Verzonden:* maandag 29 juni 2020 11:05
> *Aan:* Development list for mkgmap 
> *Onderwerp:* Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with
> default style (and other styles)
>
>
>
> Hi
>
>
>
> I finished testing and it narrows down to 4360
>
>
>
> Kind regards, Joris
>
>
>
>
>
> *Build date*
>
> *Mkgmap*
>
> *Device*
>
> *Style*
>
> *Pink line*
>
> *Crash/Deadloop*
>
> *Result*
>
> *Comment*
>
> 24-8-2017
>
> r3995
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> Yes
>
> No
>
> Ok
>
> r4195
>
> Felix Hartmann
>
> Felix Personal
>
> ?
>
> Wrong
>
> Felix thinks he uses this version and his own style but is not sure
>
> 16-4-2019
>
> r4286
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> Yes
>
> No
>
> Ok
>
> 26-10-2019
>
> r4323
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> Yes
>
> No
>
> Ok
>
>
>
> r4358
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> Yes
>
> No
>
> Ok
>
>
>
>
>
> *r4359*
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> Yes
>
> No
>
> Ok
>
>
>
>
>
> *r4360*
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> No
>
> No
>
> Wrong
>
> This is what Ticker suspected and also Steve suggested. 4360 introduced
> new routing behavior by design
>
>
>
> r4361
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> No
>
> No
>
> Wrong
>
>
>
>
>
> r4372
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> No
>
> No
>
> Wrong
>
>
>
> 17-11-2019
>
> r4373
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> Yes
>
> No
>
> Ok
>
> Orginally tested with jar file supplied by Jan Meisters: Thought it was
> oke!, still have the working img, but I cannot prove again this img was
> really created by that version. The Jar version of Steve creates an img
> that is not oke? 2nd & 3th time compile again with Jan's jar file to double
> check also suddenly is wrong: So I must have made a mistake in copy/paste
> or documenting the testresults. Conclusion 4373 is not oke
>
> 17-11-2019
>
> r4373
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> No
>
> No
>
> Wrong
>
> r4374
>
> Joris Bo
>
> Oregon 650
>
> Default 2020
>
> No
>
> Yes
>
> Wrong
>
> r4376
>
> Joris Bo
>
> Oregon 650
>
> Def

Re: [mkgmap-dev] CodePage number set to 0 after compiled

2020-06-29 Thread DD8KQ 

  
  
Hi Joris, 

since the beginning of building my own maps for my device i
  allways added this option to my map building command, at least to
  have the correct mapid in the typ-file. Here is one example, how i
  do this :
java -Xmx3m -XX:-UseGCOverheadLimit -ea -jar
  -Dlog.config=logging.properties "c:\Program Files
  (x86)\KartenTools\mkgmap\mkgmap.jar"
  --location-autofill=is_in,nearest --mapname=70030001
  --family-id=7003 .\styles\newstyle.txt --series-name="GERMANY
  TEST" --family-name="OpenStreetmap" --country-name=GERMANYTEST
  --country-abbr=GER --area-name=GER --overview-mapname="overview"
  --latin1 --style-file=.\styles --style=newstyle --max-jobs
  --keep-going --check-roundabouts --drive-on=detect,right
  --output-dir=.\out\MYGERMANY --index --bounds=.\bounds_latest
  --route --name-tag-list=name,place_name,loc_name --housenumbers
  --split-name-index --add-pois-to-areas --link-pois-to-ways
  --process-destination --process-exits --precomp-sea=.\sea_latest 
  --tdbfile --draw-priority=10 --gmapsupp -c
  .\data\MYGERMANY\template.args --description=MYGERMANY
  --remove-ovm-work-files=true 

I opened this thread only to get an idea how to get rid of the
  TYPviewer error ;-)

Am 29.06.2020 um 14:34 schrieb Joris
  Bo:


  
  
  
  
Hi Manfred,
 
I was not aware of
Tickers tip that it was possible to supply a .txt in the
same command line as the map building cmd. But it does make
sense
  😊
Always thought this
must be a .typ and since the map building scripts only
change when something gets broken I first noticed this a
couple of month ago..
So I always first
call mkgmap to create the .typ with correct codepage and
family id and immediately after this, a second call to
supply this newly  created .typ to the map build call. At
least this works for me.
 
Kind regards,
Joris
 
 
 
-Oorspronkelijk
bericht-
Van: mkgmap-dev
 Namens DD8KQ
Verzonden: maandag 29 juni 2020 13:16
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] CodePage number set to 0 after
compiled
 
Hi all, i do not compile the typ.txt
  file as own process, its integrated in my command line for
  building my maps. But every now and then, i just open the
  resulting .typ-file with the viewer and since some time i saw
  these complaining errors. In my build options to create the
  map i'm using the option --latin1, as Joris suggested. But
  nevertheless, opening the typ file with TYPviewer i get
  allways this error.
 
Am 29.06.2020 um 12:47 schrieb Ticker
  Berkin:
> Hi Manfred
> 
> Generally it is better to supply
  the TYP .txt file as an argument to
  
> mkgmap when you build your map,
  rather than compiling it as a separate
  
> process.
> 
> Otherwise, as Joris says.
> 
> Do you have a codePage specified in
  the file that is being ignored?
> [_id]
> ...
> CodePage=
> ...
> [End]
> 
> Ticker
> 
> On Mon, 2020-06-29 at 10:39 +,
  Joris Bo wrote:
>> Hi Manfed,
>> 
>> I encountered the same, since
   you must always supply the
  
>> codepage on the commandline
>> 
>> Like
>> 
>> --code-page=65001
>> Or
>> --code-page=latin1
>> 
>> 
>> Joris
>> 
>> 
>> -Oorspronkelijk
  bericht-
>> Van: mkgmap-dev 
  Namens
  
>> Manfred Haiduk
>> Verzonden: maandag 29 juni 2020
  12:29
>> Aan: Development list for
  mkgmap 
>> Onderwerp: [mkgmap-dev]
  CodePage number set to 0 after compiled
>> 
>> Hi all,
>> 
>> i don't know, if i had
  something forgotten but since some time, if i
  
>> compile my style.txt with
  mkgmap, the resulting typ-file seems to not
  
>> have any codepage number other
  than Zero. Only the TYPviewer
  
>> complains about this, on my
  device (GPSMAP 476cx) or with MapSource i
  
>> don't see any troubles. This is
  the error message the TYPviewer
  
>> generates :
>> 
>>

Re: [mkgmap-dev] CodePage number set to 0 after compiled

2020-06-29 Thread Joris Bo 
Hi Manfred,



I was not aware of Tickers tip that it was possible to supply a .txt in the 
same command line as the map building cmd. But it does make sense 😊

Always thought this must be a .typ and since the map building scripts only 
change when something gets broken I first noticed this a couple of month 
ago..

So I always first call mkgmap to create the .typ with correct codepage and 
family id and immediately after this, a second call to supply this newly  
created .typ to the map build call. At least this works for me.



Kind regards,

Joris







-Oorspronkelijk bericht-
Van: mkgmap-dev  Namens DD8KQ
Verzonden: maandag 29 juni 2020 13:16
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] CodePage number set to 0 after compiled



Hi all, i do not compile the typ.txt file as own process, its integrated in my 
command line for building my maps. But every now and then, i just open the 
resulting .typ-file with the viewer and since some time i saw these complaining 
errors. In my build options to create the map i'm using the option --latin1, as 
Joris suggested. But nevertheless, opening the typ file with TYPviewer i get 
allways this error.



Am 29.06.2020 um 12:47 schrieb Ticker Berkin:

> Hi Manfred

>

> Generally it is better to supply the TYP .txt file as an argument to

> mkgmap when you build your map, rather than compiling it as a separate

> process.

>

> Otherwise, as Joris says.

>

> Do you have a codePage specified in the file that is being ignored?

> [_id]

> ...

> CodePage=

> ...

> [End]

>

> Ticker

>

> On Mon, 2020-06-29 at 10:39 +, Joris Bo wrote:

>> Hi Manfed,

>>

>> I encountered the same, since  you must always supply the

>> codepage on the commandline

>>

>> Like

>>

>> --code-page=65001

>> Or

>> --code-page=latin1

>>

>>

>> Joris

>>

>>

>> -Oorspronkelijk bericht-

>> Van: mkgmap-dev 
>> mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
>>  Namens

>> Manfred Haiduk

>> Verzonden: maandag 29 juni 2020 12:29

>> Aan: Development list for mkgmap 
>> mailto:mkgmap-dev@lists.mkgmap.org.uk>>

>> Onderwerp: [mkgmap-dev] CodePage number set to 0 after compiled

>>

>> Hi all,

>>

>> i don't know, if i had something forgotten but since some time, if i

>> compile my style.txt with mkgmap, the resulting typ-file seems to not

>> have any codepage number other than Zero. Only the TYPviewer

>> complains about this, on my device (GPSMAP 476cx) or with MapSource i

>> don't see any troubles. This is the error message the TYPviewer

>> generates :

>>

>> *

>> *

>> 

>> Errors in the file  : D:\GPS\Maps\MYGERMANY\newstyle.typ

>> *

>> *

>> 

>>

>>

>> Unknown CodePage number: 0

>> TYPViewer has replaced it with 1252

>> If it doesn't fit, select an another CodePage number in the combobox

>> "CodePage"

>>

>>

>> Any ideas what to do ?

>>

>> btw i used mkgmap-r4487 to compile

>>

>> ___

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

> ___

> mkgmap-dev mailing list

> mkgmap-dev@lists.mkgmap.org.uk

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



--



#



  Viele Grüße und 73 de Manfred Haiduk, DD8KQ

  e-mail mhai...@t-online.de 
dd...@gmx.de



#



___

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] CodePage number set to 0 after compiled

2020-06-29 Thread DD8KQ 

Hi all, i do not compile the typ.txt file as own process, its integrated
in my command line for building my maps. But every now and then, i just
open the resulting .typ-file with the viewer and since some time i saw
these complaining errors. In my build options to create the map i'm
using the option --latin1, as Joris suggested. But nevertheless, opening
the typ file with TYPviewer i get allways this error.

Am 29.06.2020 um 12:47 schrieb Ticker Berkin:

Hi Manfred

Generally it is better to supply the TYP .txt file as an argument to
mkgmap when you build your map, rather than compiling it as a separate
process.

Otherwise, as Joris says.

Do you have a codePage specified in the file that is being ignored?
[_id]
...
CodePage=
...
[End]

Ticker

On Mon, 2020-06-29 at 10:39 +, Joris Bo wrote:

Hi Manfed,

I encountered the same, since  you must always supply the
codepage on the commandline

Like

--code-page=65001
Or
--code-page=latin1


Joris


-Oorspronkelijk bericht-
Van: mkgmap-dev  Namens
Manfred Haiduk
Verzonden: maandag 29 juni 2020 12:29
Aan: Development list for mkgmap 
Onderwerp: [mkgmap-dev] CodePage number set to 0 after compiled

Hi all,

i don't know, if i had something forgotten but since some time, if i
compile my style.txt with mkgmap, the resulting typ-file seems to not
have any codepage number other than Zero. Only the TYPviewer
complains about this, on my device (GPSMAP 476cx) or with MapSource i
don't see any troubles. This is the error message the TYPviewer
generates :

*
*

Errors in the file  : D:\GPS\Maps\MYGERMANY\newstyle.typ
*
*



Unknown CodePage number: 0
TYPViewer has replaced it with 1252
If it doesn't fit, select an another CodePage number in the combobox
"CodePage"


Any ideas what to do ?

btw i used mkgmap-r4487 to compile

___
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

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


--

#

 Viele Grüße und 73 de Manfred Haiduk, DD8KQ
 e-mail mhai...@t-online.de dd...@gmx.de

#

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] CodePage number set to 0 after compiled

2020-06-29 Thread Ticker Berkin 
Hi Manfred

Generally it is better to supply the TYP .txt file as an argument to
mkgmap when you build your map, rather than compiling it as a separate
process.

Otherwise, as Joris says.

Do you have a codePage specified in the file that is being ignored?
[_id]
...
CodePage=
...
[End]

Ticker

On Mon, 2020-06-29 at 10:39 +, Joris Bo wrote:
> Hi Manfed,
> 
> I encountered the same, since  you must always supply the
> codepage on the commandline
> 
> Like
> 
> --code-page=65001
> Or 
> --code-page=latin1
> 
> 
> Joris
> 
> 
> -Oorspronkelijk bericht-
> Van: mkgmap-dev  Namens
> Manfred Haiduk
> Verzonden: maandag 29 juni 2020 12:29
> Aan: Development list for mkgmap 
> Onderwerp: [mkgmap-dev] CodePage number set to 0 after compiled
> 
> Hi all,
> 
> i don't know, if i had something forgotten but since some time, if i
> compile my style.txt with mkgmap, the resulting typ-file seems to not
> have any codepage number other than Zero. Only the TYPviewer
> complains about this, on my device (GPSMAP 476cx) or with MapSource i
> don't see any troubles. This is the error message the TYPviewer
> generates :
> 
> *
> *
> 
> Errors in the file  : D:\GPS\Maps\MYGERMANY\newstyle.typ
> *
> *
> 
> 
> 
> Unknown CodePage number: 0
> TYPViewer has replaced it with 1252
> If it doesn't fit, select an another CodePage number in the combobox
> "CodePage"
> 
> 
> Any ideas what to do ?
> 
> btw i used mkgmap-r4487 to compile
> 
> ___
> 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] CodePage number set to 0 after compiled

2020-06-29 Thread Joris Bo 
Hi Manfed,

I encountered the same, since  you must always supply the codepage on the 
commandline

Like

--code-page=65001
Or 
--code-page=latin1


Joris


-Oorspronkelijk bericht-
Van: mkgmap-dev  Namens Manfred Haiduk
Verzonden: maandag 29 juni 2020 12:29
Aan: Development list for mkgmap 
Onderwerp: [mkgmap-dev] CodePage number set to 0 after compiled

Hi all,

i don't know, if i had something forgotten but since some time, if i compile my 
style.txt with mkgmap, the resulting typ-file seems to not have any codepage 
number other than Zero. Only the TYPviewer complains about this, on my device 
(GPSMAP 476cx) or with MapSource i don't see any troubles. This is the error 
message the TYPviewer generates :

**
Errors in the file  : D:\GPS\Maps\MYGERMANY\newstyle.typ
**


Unknown CodePage number: 0
TYPViewer has replaced it with 1252
If it doesn't fit, select an another CodePage number in the combobox "CodePage"


Any ideas what to do ?

btw i used mkgmap-r4487 to compile

___
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

[mkgmap-dev] CodePage number set to 0 after compiled

2020-06-29 Thread Manfred Haiduk 

Hi all,

i don't know, if i had something forgotten but since some time, if i 
compile my style.txt with mkgmap, the resulting typ-file seems to not 
have any codepage number other than Zero. Only the TYPviewer complains 
about this, on my device (GPSMAP 476cx) or with MapSource i don't see 
any troubles. This is the error message the TYPviewer generates :


**
Errors in the file  : D:\GPS\Maps\MYGERMANY\newstyle.typ
**


Unknown CodePage number: 0
TYPViewer has replaced it with 1252
If it doesn't fit, select an another CodePage number in the combobox 
"CodePage"



Any ideas what to do ?

btw i used mkgmap-r4487 to compile

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with default style (and other styles)

2020-06-29 Thread Joris Bo 
Update, previous version had some errors, conclusion is the same

Build date
Mkgmap
Device
Style
Pink line
Crash/Deadloop
Result
Comment
24-8-2017
r3995
Joris Bo
Oregon 650
Default 2020
Yes
No
Ok
r4195
Felix Hartmann
Felix Personal
?
Wrong
Felix thinks he uses this version and his own style but is not sure
16-4-2019
r4286
Joris Bo
Oregon 650
Default 2020
Yes
No
Ok
26-10-2019
r4323
Joris Bo
Oregon 650
Default 2020
Yes
No
Ok

r4358
Joris Bo
Oregon 650
Default 2020
Yes
No
Ok


r4359
Joris Bo
Oregon 650
Default 2020
Yes
No
Ok


r4360
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
This is what Ticker suspected and also Steve suggested. 4360 introduced new 
routing behaviour by design

r4361
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong


r4372
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong

17-11-2019
r4373
Joris Bo
Oregon 650
Default 2020
Yes
No
Ok
Orginally tested with jar file supplied by Jan Meisters: Thought it was oke!, 
still have the working img, but I cannot prove again this img was really 
created by that version. The Jar version of Steve creates an img that is not 
oke? 2nd & 3th time compile again with Jan's jar file to double check also 
suddenly is wrong: So I must have made a mistake in copy/paste or documenting 
the testresults. Conclusion 4373 is not oke
17-11-2019
r4373
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
r4374
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
r4376
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
r4379
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
6-12-2019
r4384
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
8-12-2019
r4386
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
25-1-2020
r4431
Joris Bo
Oregon 650
Default 2020
No
?
Wrong
r4479
Jan Meisters
Oregon 450
Jan Personal
No
No
Half
19-6-2020
r4551
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
19-6-2020
r4551
Joris Bo
Oregon 650
Joris Personal
No
No
Half



Van: mkgmap-dev  Namens Joris Bo
Verzonden: maandag 29 juni 2020 11:05
Aan: Development list for mkgmap 
Onderwerp: Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with default 
style (and other styles)


Hi



I finished testing and it narrows down to 4360



Kind regards, Joris




Build date
Mkgmap
Device
Style
Pink line
Crash/Deadloop
Result
Comment
24-8-2017
r3995
Joris Bo
Oregon 650
Default 2020
Yes
No
Ok
r4195
Felix Hartmann
Felix Personal
?
Wrong
Felix thinks he uses this version and his own style but is not sure
16-4-2019
r4286
Joris Bo
Oregon 650
Default 2020
Yes
No
Ok
26-10-2019
r4323
Joris Bo
Oregon 650
Default 2020
Yes
No
Ok

r4358
Joris Bo
Oregon 650
Default 2020
Yes
No
Ok


r4359
Joris Bo
Oregon 650
Default 2020
Yes
No
Ok


r4360
Joris Bo
Oregon 650
Default 2020
No
No
Wrong
This is what Ticker suspected and also Steve suggested. 4360 introduced new 
routing behavior by design

r4361
Joris Bo
Oregon 650
Default 2020
No
No
Wrong


r4372
Joris Bo
Oregon 650
Default 2020
No
No
Wrong

17-11-2019
r4373
Joris Bo
Oregon 650
Default 2020
Yes
No
Ok
Orginally tested with jar file supplied by Jan Meisters: Thought it was oke!, 
still have the working img, but I cannot prove again this img was really 
created by that version. The Jar version of Steve creates an img that is not 
oke? 2nd & 3th time compile again with Jan's jar file to double check also 
suddenly is wrong: So I must have made a mistake in copy/paste or documenting 
the testresults. Conclusion 4373 is not oke
17-11-2019
r4373
Joris Bo
Oregon 650
Default 2020
No
No
Wrong
r4374
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
r4376
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
r4379
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
6-12-2019
r4384
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
8-12-2019
r4386
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
25-1-2020
r4431
Joris Bo
Oregon 650
Default 2020
No
?
Wrong
r4479
Jan Meisters
Oregon 450
Jan Personal
No
No
Half
19-6-2020
r4551
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
19-6-2020
r4551
Joris Bo
Oregon 650
Joris Personal
No
No
Half





-Oorspronkelijk bericht-
Van: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 Namens Steve Ratcliffe
Verzonden: zondag 28 juni 2020 10:22
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with default 
style (and other styles)





Hi Joris



> Based on the versions supplied I could bring it down to 4373 still being  > 
> OK and 4384 reveals the problem



Thanks for narrowing it down.



There was a large change not long before that in version 4360 with the merge of 
the NET-no-NOD branch that did affect the routing a lot.



It causes the NodCheck utility to crash, I don't know why yet.



I've put all precompiled jar files at: http://www.mkgmap.org.uk/jars/



Steve



___

mkgmap-dev mailing list

mkgmap-dev@lists.mkgmap.org.uk

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
__

Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with default style (and other styles)

2020-06-29 Thread Joris Bo 
Hi



I finished testing and it narrows down to 4360



Kind regards, Joris




Build date
Mkgmap
Device
Style
Pink line
Crash/Deadloop
Result
Comment
24-8-2017
r3995
Joris Bo
Oregon 650
Default 2020
Yes
No
Ok
r4195
Felix Hartmann
Felix Personal
?
Wrong
Felix thinks he uses this version and his own style but is not sure
16-4-2019
r4286
Joris Bo
Oregon 650
Default 2020
Yes
No
Ok
26-10-2019
r4323
Joris Bo
Oregon 650
Default 2020
Yes
No
Ok

r4358
Joris Bo
Oregon 650
Default 2020
Yes
No
Ok


r4359
Joris Bo
Oregon 650
Default 2020
Yes
No
Ok


r4360
Joris Bo
Oregon 650
Default 2020
No
No
Wrong
This is what Ticker suspected and also Steve suggested. 4360 introduced new 
routing behavior by design

r4361
Joris Bo
Oregon 650
Default 2020
No
No
Wrong


r4372
Joris Bo
Oregon 650
Default 2020
No
No
Wrong

17-11-2019
r4373
Joris Bo
Oregon 650
Default 2020
Yes
No
Ok
Orginally tested with jar file supplied by Jan Meisters: Thought it was oke!, 
still have the working img, but I cannot prove again this img was really 
created by that version. The Jar version of Steve creates an img that is not 
oke? 2nd & 3th time compile again with Jan's jar file to double check also 
suddenly is wrong: So I must have made a mistake in copy/paste or documenting 
the testresults. Conclusion 4373 is not oke
17-11-2019
r4373
Joris Bo
Oregon 650
Default 2020
No
No
Wrong
r4374
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
r4376
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
r4379
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
6-12-2019
r4384
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
8-12-2019
r4386
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
25-1-2020
r4431
Joris Bo
Oregon 650
Default 2020
No
?
Wrong
r4479
Jan Meisters
Oregon 450
Jan Personal
No
No
Half
19-6-2020
r4551
Joris Bo
Oregon 650
Default 2020
No
Yes
Wrong
19-6-2020
r4551
Joris Bo
Oregon 650
Joris Personal
No
No
Half





-Oorspronkelijk bericht-
Van: mkgmap-dev  Namens Steve Ratcliffe
Verzonden: zondag 28 juni 2020 10:22
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with default 
style (and other styles)





Hi Joris



> Based on the versions supplied I could bring it down to 4373 still being  > 
> OK and 4384 reveals the problem



Thanks for narrowing it down.



There was a large change not long before that in version 4360 with the merge of 
the NET-no-NOD branch that did affect the routing a lot.



It causes the NodCheck utility to crash, I don't know why yet.



I've put all precompiled jar files at: http://www.mkgmap.org.uk/jars/



Steve



___

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] mapnik typ file and barrier=wall

2020-06-29 Thread Ticker Berkin 
Hi all

I've just been testing constructs that 'break routing' and I can
confirm that using any of:

# 0x2c Nothing/Line. BaseCamp shows nothing even with TYP
# 0x2d Climbing Path. MapSource shows nothing "
# 0x2e Via Ferrata. MapSource shows nothing "
# 0x2f Cable Car. MapSource shows nothing "

for non-routable lines breaks BaseCamp routing in some serious ways.
MapSource routing works, as do my eTrex HCx and 30x. 

We don't use any of these in styles/default/lines. I haven't tested
these types for routable lines.

Ticker

On Mon, 2020-02-03 at 18:23 +, Joris Bo wrote:
> Hi
> 
> To share other (i don't know why) issues I once encountered.
> 
> 0x17  Does not show a line. Don't use : maybe only be used as
> transparent overlay feature
> 0x2c  If used: Lines are visible but breaks car-routing
> 0x2d  If used: Lines are visible but breaks car-routing
> 0x10201   Don't use
> 0x10202   Don't use
> 0x10b05 to 0x10b1fNo lines visible
> 
> 
> 
> Kind regards
> Joris

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev