Re: [mkgmap-dev] Problems with -- gmapi (and possibly --gmapsupp also)

to find/identify an existing overview map. Gerd Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Patrik Brunner <patrik.brun...@gmx.net> Gesendet: Mittwoch, 8. Februar 2017 21:33:53 An: mkgmap-dev@lists.mkgmap.org.uk Betreff:

Re: [mkgmap-dev] Problems with -- gmapi (and possibly --gmapsupp also)

Steve, Folder structure looks the same as with for example jmc_cli. It doesn't make a difference if I call mkgmap --gmapsupp with the overview parameters (--overview-mapname=... --overview-mapnumber=...), in no case I have overview maps. The only difference is how the files are named inside

Re: [mkgmap-dev] Problems with -- gmapi (and possibly --gmapsupp also)

oun...@lists.mkgmap.org.uk> im Auftrag von Patrik Brunner <patrik.brun...@gmx.net> Gesendet: Sonntag, 5. Februar 2017 16:20:08 An: Development list for mkgmap Betreff: [mkgmap-dev] Problems with -- gmapi (and possibly --gmapsupp also) Gents, I've just noticed that the quite new option

[mkgmap-dev] Problems with -- gmapi (and possibly --gmapsupp also)

Gents, I've just noticed that the quite new option --gmapi does not work properly regarding overview maps: - I first build the img files where all is correct, overview maps are properly built and set at the different needed locations (*.tdb file, elsewhere ?) - running mkgmap with the option

Re: [mkgmap-dev] Installer not working

Stéphane,   those effects remind me my problems earlier...   questions: - when did this problem start ? (sorry, can't read up the complete history where I am right now). - did/does it also happen wir releases prior to r3730 ?   r3730 was the release when the so called 'file-encoding'

Re: [mkgmap-dev] Copyright & License file reader improvements

Gents, skipping empty lines might be a problem or at least was one. According documentation and my own experience the first line of the file handed over via --copyright-file is not shown on the garmin devices, but on BaseCamp. In order to have all licenses properly shown on the device

Re: [mkgmap-dev] Error reading license-file

Alexandre, try to convert the license file with your editor into UTF-8 and run it again... That most problably works.   Cheers Patrik   Gesendet: Dienstag, 20. Dezember 2016 um 15:22 Uhr Von: "Alexandre Loss" An: "Development list for mkgmap"

Re: [mkgmap-dev] mkgmap option product-version and gmapsupp format

Steve, following link regarding Header Information in gmapsupp.img seems to be still valid: https://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/IMG_File_Format At least using a hex editor to change Map's major version (Byte 0x08) and minor version (Byte 0x09) did show me the expected result

[mkgmap-dev] mkgmap option product-version and gmapsupp format

Steve, as already announced: with all the intensive testing regarding unicode, gmap and others I found following in my opinion strange behaviour in relation to gmapsupp format: * my mkgmap call for gmapsupp creation contains the option '--product-version="1612"' * when checking the

Re: [mkgmap-dev] Adding the gmapi format.

Steve, Just ran a build process from a to z with merged 3731, unicode and non-unicode map. All looks fine regarding the changed/added/merged features. Also the gmap directory converted via mkgmap now looks great with unicode maps... Regarding testing: no problem at all, it's a pleasure...

Re: [mkgmap-dev] Adding the gmapi format.

'unicode' tests with the merged trunk revision r3730. Cheers Patrik On 18.12.2016 10:25, Patrik Brunner wrote: Steve, We've built a few maps more with 'old' r3727 of the gmapi branch (different sizes, up to about 1.8 GB) on Windows and Linux and did test them all on BaseCamp for Windows

Re: [mkgmap-dev] Adding the gmapi format.

for production... ;-) Many thanks for implementing it that quick and easy. Cheers Patrik On 15.12.2016 22:10, Patrik Brunner wrote: perfect: ... 1612 ... Now I'm a real happy user... ;-) I will make sure it will be tested with more, different and bigger maps. But all will be built via the same

Re: [mkgmap-dev] Adding the gmapi format.

perfect: ... 1612 ... Now I'm a real happy user... ;-) I will make sure it will be tested with more, different and bigger maps. But all will be built via the same building environment, therefore, to be honest, I do not expect any additional problems just due to other maps. I did most of the

Re: [mkgmap-dev] Adding the gmapi format.

and regards Patrik On 15.12.2016 09:05, Patrik Brunner wrote: I'll give it another try latest tomorrow. Could be that I'm not using --overview-mapname in the call I was just copying the snippets from the creation of the gmapsupp without too much additional brainwork and checks. Regarding City N

Re: [mkgmap-dev] Adding the gmapi format.

I'll give it another try latest tomorrow. Could be that I'm not using --overview-mapname in the call I was just copying the snippets from the creation of the gmapsupp without too much additional brainwork and checks.   Regarding City Navigator: I'm quite sure it didn't contain spaces, but

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

Steve, In very short: all looks fine. Bit longer: I've cleaned up the building environment and created a small map (LUX) a few times: * on linux, unicode * on linux, cp1252 * on windows, unicode * on windows, cp1252 I've checked these results the following ways: * gmap archive

Re: [mkgmap-dev] Adding the gmapi format.

I've tested the latest version from the gmapi branch and it runs fine in my opinion, I didn't find any obvious problem when using the created map inside MapSource. But I have a question/request, even though I know that the phyton script was doing it exactly the same way. Right now the gmap

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

). As it looks right now: I would guess, that you solved the issues great. Many thanks... I'll let you know latest test results in a few days. Thanks and regards Patrik On 13.12.2016 09:03, Patrik Brunner wrote: Steve, Thanks. I'm checking at the same location in BaseCamp... Following things

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

Steve, Thanks.   I'm checking at the same location in BaseCamp...   Following things can/have to be mentioned: I'm calling java with the option file-encoding=utf8 (or similar, can't remember by heart), this means, mkgmap is started also in utf8 environment, independant if it's run on

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

tests, just let me know. Cheers Patrik On 11.12.2016 23:48, Patrik Brunner wrote: I will try to test it tomorrow evening... Thanks Patrik Am 11.12.2016 23:29 schrieb Steve Ratcliffe <st...@parabola.me.uk>: Hi The file-encoding branch now appears to work with both cop

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

I will try to test it tomorrow evening...ThanksPatrikAm 11.12.2016 23:29 schrieb Steve Ratcliffe : Hi The file-encoding branch now appears to work with both copyright and licence files and --unicode.  I've checked with BaseCamp. Both are added in mixed case,

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

sorry for having opened Pandora's Box... ;-) Consider me as a good and willing tester I'll just fetch the new branch to my local repo. Cheers Patrik On 11.12.2016 14:39, Steve Ratcliffe wrote: I've started a branch for this as the problems I'm discovering are increasing rapidly! So in

Re: [mkgmap-dev] Adding the gmapi format.

Steve, Yes, normally you just have to move (or link) the *.gmap directory to the correct place on your system and BaseCamp will recognice it. I never used a *.gmapi container around it with osm maps. For me personally it does not make a too big difference as I move the directory anyway

Re: [mkgmap-dev] Adding the gmapi format.

Steve, confirmed: adding the appropriate --code-page=something (depending on what the source map is) does get rid of the warnings... Patrik On 05.12.2016 22:43, Steve Ratcliffe wrote: Hi java -Xmx1536M -Dfile.encoding=UTF-8 -jar

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

confirmed... adding the proper --code-page=something works also for compiling TYP files. And I've just noticed that creating the gmapsupp file fails with the latest patch for unicode licenses with the the same exception if I do not add the codepage Adding --code-page=anything there does

Re: [mkgmap-dev] Adding the gmapi format.

r of ExitExceptions: 0 Time finished: Mon Dec 05 21:45:22 CET 2016 Total time taken: 1763ms I assume we're able to choose the filename too lateron ? Cheers Patrik On 05.12.2016 20:32, Patrik Brunner wrote: I'm happy to test the actual version also is there a prebuilt jar file ?

Re: [mkgmap-dev] Adding the gmapi format.

I'm happy to test the actual version also is there a prebuilt jar file ? sorry, I'm not the Java Crack... ;-) Cheers Patrik On 05.12.2016 17:14, Andrzej Popowski wrote: Hi Steve, I have run a simple compilation and map works correctly in Mapsource. My suggestion is to drop

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

Steve, I've just replaced the mkgmap.jar and started the process again unfortunately it's not running through and throws an exception when trying to compile the TYP files (independant if I try to build unicode things or cp1252 things): java -Xmx1536M -jar

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

not create such data leak. ... just tried it out now with building cp1252 map as it happened here also. Cheers Patrik On 04.12.2016 18:47, Patrik Brunner wrote: When checked via BaseCamp while the eTrex or the oregon 450t is hooked up to my machine: * Scrambled Characters for the special

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

Ratcliffe wrote: On 04/12/16 17:16, Patrik Brunner wrote: no luck think it got worse as there is now suddenly text in (I assume) the copyright section which belongs to the map: 'Centre de Conf). Here just copy paste of the text inside the Copyright Dialog Box of Basecamp: Hmm, what does

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

no luck think it got worse as there is now suddenly text in (I assume) the copyright section which belongs to the map: 'Centre de Conf). Here just copy paste of the text inside the Copyright Dialog Box of Basecamp: (c) Contour data: U.S. Geological Survey or J. de Ferranti (free

Re: [mkgmap-dev] Feature Request: mkgmap able to create gmap archive (BaseCamp)

, so yes, that may be the case. I have changed gmapi-builder permissions, you should be able to download it now El 04/12/16 a las 16:48, Patrik Brunner escribió: Just to let everyone know: I get this 'Unknown Block' Output only when I run gmapi-builder.py with the option -v for verbose. Without

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

Steve, that sounds like a plan... ;-) Regarding lower-case option again: I found old screenprints from one of my devices from early last year, showing all capital letters for streetnames and similar... sometime last year it seems to have changed. Newer screenprints from the device always show

Re: [mkgmap-dev] Feature Request: mkgmap able to create gmap archive (BaseCamp)

Just to let everyone know: I get this 'Unknown Block' Output only when I run gmapi-builder.py with the option -v for verbose. Without -v it's not shown. Would it be possible that others just haven't seen it as they didn't use the verbose option ? Cheers Patrik On 04.12.2016 16:34, Greg

Re: [mkgmap-dev] Feature Request: mkgmap able to create gmap archive (BaseCamp)

that error. On 4 December 2016 10:38:27 GMT+00:00, Patrik Brunner <patrik.brun...@gmx.net> wrote: thomas, thanks for the explanation. Source files (map itself and typ files) handed over to gmapi-builder.py have just been created one step before by mkgmap. I've just made the same process with a

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

Steve, here some answers for below questions: -> Can you tell me what characters you do see instead? For unicode map option copyright-file I see characters that look like black diamonds with a question mark in it (picture attached, hope it comes through). -> lower-case option I've double

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

for having a nice license as I might loose support for some devices ? Cheers Patrik On 03.12.2016 22:51, Patrik Brunner wrote: Steve, great news. Just a very quick feedback without having done much testing... I've just exchanged mkgmap.jar and built a unicode and a cp1252 map. If I didn't mess

Re: [mkgmap-dev] Feature Request: mkgmap able to create gmap archive (BaseCamp)

0x54+12=Int((nCRCSum - vByteD * 16777216) / 65536) ' vByteC 0x54+15=Int((nCRCSum - vByteD * 16777216 - vByteC * 65536) / 256) 'vByteB 0x54+20=Int(nCRCSum - vByteD * 16777216 - vByteC * 65536 - vByteB * 256) all other bytes=0 thomas Am 04.12.2016 um 10:40 schrieb Patrik Brunner: Steve

Re: [mkgmap-dev] Feature Request: mkgmap able to create gmap archive (BaseCamp)

Steve, I've downloaded both versions of gmapi-builder.py, the one from bitbucket and the one from the mkgmap code base. They're bit different and I couldn't find a version number when checking quickly, but only the mkgmap version supports -i for mdx files. Therefore I continued with the

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

Steve, great news. Just a very quick feedback without having done much testing... I've just exchanged mkgmap.jar and built a unicode and a cp1252 map. If I didn't mess anything up on my end I would guess: * it looks like you found the correct hook * when building unicode map either

Re: [mkgmap-dev] Feature Request: mkgmap able to create gmap archive (BaseCamp)

Yes I know, on each platform there are different options it's not the question about how to convert it on the different platforms, there are on each platform several options, but most of the times you have to choose different ways to go, depending on the platform. There's even a cli

Re: [mkgmap-dev] Feature Request: mkgmap able to create gmap archive (BaseCamp)

) on the different platforms mac, windows and linux. Patrik On 03.12.2016 15:10, Thomas Morgenstern wrote: I see no needs for that. Garmin Mapconverter does this job very well. thomas Am 03.12.2016 um 14:22 schrieb Patrik Brunner: Hello together, I'm wondering if it would be possible

[mkgmap-dev] Feature Request: mkgmap able to create gmap archive (BaseCamp)

Hello together, I'm wondering if it would be possible that mkgmap is able to create/convert maps also in the gmap (gmapi) format used for BaseCamp on Windows and Macintosh. Allthough the old image directory style format is still supported at least on Windows BaseCamp with fiddling around in

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

Steve, where you able to investigate some more ? Is there another build I can/have to try it with ? Cheers Patrik On 27.11.2016 22:05, Steve Ratcliffe wrote: Hi Patrik It looks different and better, but not yet completely good yet: * it's consistent now (tested on Windows only for the

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

On 27.11.2016 21:59, Steve Ratcliffe wrote: On 26/11/16 22:37, Patrik Brunner wrote: Another important thing to note about the release you created: Suddenly the cfg file has to be utf-8 also. I have some special What do you mean by the cfg file? A -c or --read-config option? I didn't change

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

Steve, Thanks for the updated version. It looks different and better, but not yet completely good yet: * it's consistent now (tested on Windows only for the moment), independant if I start with or without -Dfile.encoding=utf * If I create a Latin1 map (codepage 1252) the licens looks good

Re: [mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

Thanks Steve, Good to have that different behaviour explained/confirmed. If there's anything to be tested, just let me know I would just need patched/updated mkgmap as I'm not the Java Crack in terms of compilations... Best wishes too. Patrik On 25.11.2016 23:36, Steve Ratcliffe wrote:

[mkgmap-dev] mkgmap: problems with encoding file used with option --license-file

Hello together, I'm using makemap (r3696) on Windows (non UTF-8 locale) and on Linux (UTF-8 locale) and got very strange and platform dependant behaviour. So I started to use the option -Dfile.encoding=utf-8 in the java call of mkgmap to have at least the same, still strange and different

Re: [mkgmap-dev] "Invalid rule expression" for expression in line file after upgrade from r3649 to r3693

sort of late... but nevertheless: many thanks. Patrik On 18.08.2016 23:50, Steve Ratcliffe wrote: Hi I assume that solution will make its way into the next official release It is now in mkgmap-r3694 Thanks, ..Steve ___ mkgmap-dev mailing list

Re: [mkgmap-dev] "Invalid rule expression" for expression in line file after upgrade from r3649 to r3693

Steve, just testet out the intermediate mkgmap.jar. I can confirm that it now runs through again with both versions of my expression, the inital one that triggered the error as well as the rearranged one which I used as a workaround. I assume that solution will make its way into the next

[mkgmap-dev] "Invalid rule expression" for expression in line file after upgrade from r3649 to r3693

Gents, With newest release r3693 I'm having troubles creating a map with a style file 'line' containing the following expression (it worked with r3649 and earlier version): maxspeed = * & ( maxspeedkmh()>120 | maxspeed = none ) & ( highway = motorway | highway = trunk ) { set

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

t thought that I cannot use --ignore-osm-bounds as option name) Gerd Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Patrik Brunner <patrik.brunner@gmx.net> Gesendet: Freitag, 25. März 2016 13:32 An: mkgmap-dev@lists.mkgmap.org.uk Betre

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

. reg. implementation: I don't see any problem for any of the three options, but option 3 may requrie more thoughts. Gerd *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Patrik Brunner <pa

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

on't need the files, I downloaded the alaska file and tried some variants. See also my last post, send a few minutes ago. Gerd *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Patrik Brunne

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Gerd, Yes, alaska.osm.pbf is small. It works without --no-trim. And it also works with the polygon file that belongs to alaska.osm.pbf (also downloaded from Geofabrik) which, according to documentation, anyway would disable --no-trim option. Do you still need the resulting densities-out of

Re: [mkgmap-dev] Problem with splitter r412: invalid bbox area in pbf file

Gerd, many thanks. I think I got the point: * splitter fails on a wrong bounds tag if that one would be absent it would check real bounds according existing nodes. * osmconvert doesn't read out that wrong tag (else it would be the 'wrong bounds' too) but just reports bounds

Re: [mkgmap-dev] r3008 in high-prec-coord branch

Gerd, Any details about the changes ? Would be interested to know more. Thanks Patrik Gerd Petermann gpetermann_muenc...@hotmail.com schrieb: Hi all, FYI: I plan a major change in the polygon cutting algos during the next days, so I think r3008

Re: [mkgmap-dev] r3008 in high-prec-coord branch

Sure that's ok... always tried to follow it, but looks like I have to go sort of deeper into it... ;-) Thanks Patrik On 05.02.2014 17:37, GerdP wrote: Hi Patrik, please check the svn log entries:

Re: [mkgmap-dev] bounds and sea on pleiades

to achieve and I'll add an easier link with the next update. On 31-01-14 15:37, Patrik Brunner wrote: Lambertus, Actually you have a directory ./latest in both your sea and bounds directory in which we can find the latest version of the sea and and the bounds file. Unfortunately these files still

Re: [mkgmap-dev] bounds and sea on pleiades

the sea generator and will run that one later. On 04-02-14 18:42, Patrik Brunner wrote: Lambertus, I've seen that the 'bounds' is already handled with the new concept: http://osm2.pleiades.uni-wuppertal.de/bounds/latest/bounds.zip But the sea boundaries are not yet done the same way even

[mkgmap-dev] bounds and sea on pleiades

Lambertus, Actually you have a directory ./latest in both your sea and bounds directory in which we can find the latest version of the sea and and the bounds file. Unfortunately these files still have the date tag in the name which makes an automatic 'fix' download of the latest boundaries

Re: [mkgmap-dev] bounds and sea on pleiades

. Januar 2014, 15:37:50 schrieb Patrik Brunner: So one could always download the latest file from the paths ./bounds/latest/bounds.zip and ./sea/latest/sea.zip Not sure how complex it is to achieve this during your automated generation/preparation/publishing, but guessing from my scripting experience

Re: [mkgmap-dev] bounds and sea on pleiades

Good news many thanks, Lambertus. Anything fixed (not changing with different releases) will do it. Regards Patrik On 31.01.2014 19:18, Lambertus wrote: This is not hard to achieve and I'll add an easier link with the next update. On 31-01-14 15:37, Patrik Brunner wrote: Lambertus

Re: [mkgmap-dev] boundary France broken?

Confirmed, France is back... but Norway is still missing on the latest zips provided by WanMil: Cheers Patrik On 25.01.2014 09:56, Minko wrote: Thanks, France is back on the map! :-) ___ mkgmap-dev

Re: [mkgmap-dev] boundary France broken?

Patrik Brunner wrote Confirmed, France is back... but Norway is still missing on the latest zips provided by WanMil: Cheers Patrik On 25.01.2014 09:56, Minko wrote: Thanks, France is back on the map! :-) ___ mkgmap-dev mailing list mkgmap-dev@.org

Re: [mkgmap-dev] boundary France broken?

Lambertus, File properly downloadable, thanks for your efforts it seems to contain properly both France and Norway, allthough that's sort of unclear to me, but never mind. Question: will you also provide the precompiled sea boundaries in a similar way ? Regards Patrik On 25.01.2014

Re: [mkgmap-dev] boundary France broken?

WanMil, Can't download the files from there both links unavailable... Cheers Patrik On 24.01.2014 17:56, WanMil wrote: Hi Minko, I have recompiled them with fresh data: bounds: http://46.249.37.15/wanmil/bounds_20140124.zip sea: http://46.249.37.15/wanmil/sea_20140123.zip WanMil Hi

Re: [mkgmap-dev] boundary France broken?

Lambertus, I hope you also create somehow a version tag inside the two directories like it was done in the script of WanMil... this allows users to easily check which version of the boundaries is downloaded/used, even if the files were copied and lost therefore the creation date. The

Re: [mkgmap-dev] boundary France broken?

Many Thanks, Lambertus... On 24.01.2014 22:26, Lambertus wrote: No worries, the version file will be included in the zip. :) On 24-01-14 22:22, Patrik Brunner wrote: Lambertus, I hope you also create somehow a version tag inside the two directories like it was done in the script of WanMil

Re: [mkgmap-dev] boundary France broken?

after copy+paste. Gerd Patrik Brunner wrote Is that now good or bad ? It's still running on admin_level 5 but I assume that level 2 is finished. BTW: my Windows Java did complain about the option --Xmx6800m I assume it should be a single dash, not doubledash... therefore -Xmx6800m I've just

Re: [mkgmap-dev] TYP-file can't be written

the CodePage correct, or leave it out altogether and then it will be taken from the command line. But if it is taken from the command line then it will still fail if you specify a code-page that is not compatible with the code page that the typ is actually in. ..Steve On 17/12/13 22:31, Patrik

Re: [mkgmap-dev] TYP-file can't be written

Henning, think it's clear now my perspective (and the one the initial 'fix' was based on) was mainly TYP file compiler biased obviously the other aspect about different codepages in map was overlooked. It would be a possibility to handle the map CP and the TYP CP with different

Re: [mkgmap-dev] TYP-file can't be written

Steve, This means that everyone needs to make everywhere sure that the correct stuff is written inside the source file... I really think it's the more convenient way to have: 1. The CP taken from the source file is the the one 'normally' used 2. CLI Argument 'overrules' the content of the TYP