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

2016-12-04 Thread Carlos Dávila 

Right. This is my complete command for gmapi:
python gmapi-builder.py -t tmp/$ABR-1${FID}.tdb -b tmp/$ABR-1${FID}.img 
-i tmp/$ABR-1${FID}.mdx -m tmp/$ABR-1${FID}_mdr.img -s 
typ/${ABR}-1$FID.TYP tmp/551${FID}*.img tmp/$ABR-1${FID}*.img


El 05/12/16 a las 00:30, Steve Ratcliffe escribió:

Oh I see, you are just meant to include the overview map along with the
other IMG files as well as the -b option.

On 4 December 2016 23:01:35 GMT+00:00, Steve Ratcliffe  
wrote:

On 04/12/16 22:57, Carlos Dávila wrote:

El 04/12/16 a las 23:35, Steve Ratcliffe escribió:

I notice that the python script does not seem to deal with the
overview map.  Is that correct?

It should work with -b option

I use the -b option and just get the following:

$ find OSM\ map.gmapi/
OSM map.gmapi/
OSM map.gmapi/OSM map.gmap
OSM map.gmapi/OSM map.gmap/Info.xml
OSM map.gmapi/OSM map.gmap/OSMTiles
OSM map.gmapi/OSM map.gmap/OSMTiles/63240001
OSM map.gmapi/OSM map.gmap/OSMTiles/63240001/63240001.LBL
OSM map.gmapi/OSM map.gmap/OSMTiles/63240001/63240001.NOD
OSM map.gmapi/OSM map.gmap/OSMTiles/63240001/63240001.TRE
OSM map.gmapi/OSM map.gmap/OSMTiles/63240001/63240001.RGN
OSM map.gmapi/OSM map.gmap/OSMTiles/63240001/63240001.NET
OSM map.gmapi/OSM map.gmap/OSMTiles/osmmap.tdb

There should be files like:

  OSM map.gmapi/OSM map.gmap/OSMTiles/osmmap/6324.RGN
  OSM map.gmapi/OSM map.gmap/OSMTiles/osmmap/6324.TRE
  ...

..Steve


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

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

2016-12-04 Thread Steve Ratcliffe 
Oh I see, you are just meant to include the overview map along with the
other IMG files as well as the -b option.

On 4 December 2016 23:01:35 GMT+00:00, Steve Ratcliffe  
wrote:
>On 04/12/16 22:57, Carlos Dávila wrote:
>> El 04/12/16 a las 23:35, Steve Ratcliffe escribió:
>>> I notice that the python script does not seem to deal with the
>>> overview map.  Is that correct?
>>
>> It should work with -b option
>
>I use the -b option and just get the following:
>
>$ find OSM\ map.gmapi/
>OSM map.gmapi/
>OSM map.gmapi/OSM map.gmap
>OSM map.gmapi/OSM map.gmap/Info.xml
>OSM map.gmapi/OSM map.gmap/OSMTiles
>OSM map.gmapi/OSM map.gmap/OSMTiles/63240001
>OSM map.gmapi/OSM map.gmap/OSMTiles/63240001/63240001.LBL
>OSM map.gmapi/OSM map.gmap/OSMTiles/63240001/63240001.NOD
>OSM map.gmapi/OSM map.gmap/OSMTiles/63240001/63240001.TRE
>OSM map.gmapi/OSM map.gmap/OSMTiles/63240001/63240001.RGN
>OSM map.gmapi/OSM map.gmap/OSMTiles/63240001/63240001.NET
>OSM map.gmapi/OSM map.gmap/OSMTiles/osmmap.tdb
>
>There should be files like:
>
>  OSM map.gmapi/OSM map.gmap/OSMTiles/osmmap/6324.RGN
>  OSM map.gmapi/OSM map.gmap/OSMTiles/osmmap/6324.TRE
>  ...
>
>..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] Feature Request: mkgmap able to create gmap archive (BaseCamp)

2016-12-04 Thread Steve Ratcliffe 

On 04/12/16 22:57, Carlos Dávila wrote:

El 04/12/16 a las 23:35, Steve Ratcliffe escribió:

I notice that the python script does not seem to deal with the
overview map.  Is that correct?


It should work with -b option


I use the -b option and just get the following:

$ find OSM\ map.gmapi/
OSM map.gmapi/
OSM map.gmapi/OSM map.gmap
OSM map.gmapi/OSM map.gmap/Info.xml
OSM map.gmapi/OSM map.gmap/OSMTiles
OSM map.gmapi/OSM map.gmap/OSMTiles/63240001
OSM map.gmapi/OSM map.gmap/OSMTiles/63240001/63240001.LBL
OSM map.gmapi/OSM map.gmap/OSMTiles/63240001/63240001.NOD
OSM map.gmapi/OSM map.gmap/OSMTiles/63240001/63240001.TRE
OSM map.gmapi/OSM map.gmap/OSMTiles/63240001/63240001.RGN
OSM map.gmapi/OSM map.gmap/OSMTiles/63240001/63240001.NET
OSM map.gmapi/OSM map.gmap/OSMTiles/osmmap.tdb

There should be files like:

 OSM map.gmapi/OSM map.gmap/OSMTiles/osmmap/6324.RGN
 OSM map.gmapi/OSM map.gmap/OSMTiles/osmmap/6324.TRE
 ...

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

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

2016-12-04 Thread Carlos Dávila 

El 04/12/16 a las 23:35, Steve Ratcliffe escribió:

I notice that the python script does not seem to deal with the
overview map.  Is that correct? 


It should work with -b option


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

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

2016-12-04 Thread Steve Ratcliffe 


Hi


Any chance ? I'm happy to test whatever is needed.


There is now a gmapi branch for developing this.

There is an initial version with the following limitations:

- Only the default family-id, names etc
- No index or typ files etc
- There is no option it just always creates an osmmap.gmapi directory.
- It may well not work, I've got nothing to test it with.

I notice that the python script does not seem to deal with the
overview map.  Is that correct?

You can download from the bottom of the regular download page
it will have a name like mkgmap-gmapi-r3708.zip

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

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

2016-12-04 Thread Steve Ratcliffe 


Hi Patrik

Please try this one: http://files.mkgmap.org.uk/download/319/mkgmap.jar

The important file for this change is the tdb file.
Previously the copyright information was always
encoded with cp1252 whatever the declared code page was.

So this makes a lot more sense, sorry about the last one as I wasn't 
thinking straight!


This change does not affect anything on the device, if you
used a gmapsupp created by mkgmap.

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

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

2016-12-04 Thread Steve Ratcliffe 
Hi

Not sure about the leaking, but please just ignore the last jar file I sent 
out.  Sorry about that.

Steve 

On 4 December 2016 18:23:03 GMT+00:00, Patrik Brunner  
wrote:
>Additional Info regarding the 'leaked' data from the map, just noticed:
>
>Building a cp1252 map now shows also additional stuff in the BaseCamp 
>Copyright Dialog Box:
>Centre de Conférence et de Congrès International (Salle municipale)
>
>And I think I have the reason for 'leaking' map data into copyright 
>dialog box:
>As written in the mkgmap description the first line of the file handed 
>over to copyright-file option is not shown on the device.
>Clever as I am I've just put an empty line in front of the three needed
>
>lines looks like this was not that clever, as it screws up the 
>process additionally.
>
>But that, I would guess, a different construction area again, here the 
>facts so far:
>
>  * If I have either only copyright-file or only license-file activated
>with the empty line, nothing bad happens.
>  * This leaking happens only if have have the file starting with an
>empty line handed over to both options.
>  * A single space instead of a complete empty line does also not help.
>  * Rolling back one release to the one you've sent me yesterday helps,
>the leaked information is gone.
> * Rolling back to the version of the 26th Nov (first one with build nr
>3704) also does 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 characters  shown only
>> once (as the license-file thingy is missing on the device anyway)
>>
>> © (c) Contour data: U.S. Geological Survey or J. de Ferranti (free
>for 
>> research and private use)
>> © (c) Map data: Osm contributors �� (Odbl)
>> © (c) Map: Fzk project �� (free for research and private use)
>>
>> Directly on the device itself (tested both eTrex and oregon):
>>
>>   * No additional stuff shown as in BaseCamp directly (the stuff that
>> belongs to the map)
>>   * No special characters shown, looks like it cuts off everything on
>> the line before the first special character.
>>
>> It looks more or less (put together manually):
>>
>> © (c) Map: Fzk project
>> © (c) Map data: Osm contributors
>> © (c) Contour data: U.S. Geological Survey or J. de Ferranti (free
>for 
>> research and private use)
>>
>> And just to clarify again: the source file for the the option 
>> license-file and for the option copyright-file is the same file, it's
>
>> only one file. And this is, according to my editors, properly
>utf8 :-(
>> Strange stuff... ;-)
>>
>> Cheers
>> Patrik
>>
>> On 04.12.2016 18:30, Steve 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 it look like on the device?
>>>
>>> Cheers,
>>> ..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
>
>
>
>
>
>___
>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] mkgmap: problems with encoding file used with option --license-file

2016-12-04 Thread Patrik Brunner 

Additional Info regarding the 'leaked' data from the map, just noticed:

Building a cp1252 map now shows also additional stuff in the BaseCamp 
Copyright Dialog Box:

Centre de Conférence et de Congrès International (Salle municipale)

And I think I have the reason for 'leaking' map data into copyright 
dialog box:
As written in the mkgmap description the first line of the file handed 
over to copyright-file option is not shown on the device.
Clever as I am I've just put an empty line in front of the three needed 
lines looks like this was not that clever, as it screws up the 
process additionally.


But that, I would guess, a different construction area again, here the 
facts so far:


 * If I have either only copyright-file or only license-file activated
   with the empty line, nothing bad happens.
 * This leaking happens only if have have the file starting with an
   empty line handed over to both options.
 * A single space instead of a complete empty line does also not help.
 * Rolling back one release to the one you've sent me yesterday helps,
   the leaked information is gone.
 * Rolling back to the version of the 26th Nov (first one with build nr
   3704) also does 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 characters  shown only
once (as the license-file thingy is missing on the device anyway)

© (c) Contour data: U.S. Geological Survey or J. de Ferranti (free for 
research and private use)

© (c) Map data: Osm contributors �� (Odbl)
© (c) Map: Fzk project �� (free for research and private use)

Directly on the device itself (tested both eTrex and oregon):

  * No additional stuff shown as in BaseCamp directly (the stuff that
belongs to the map)
  * No special characters shown, looks like it cuts off everything on
the line before the first special character.

It looks more or less (put together manually):

© (c) Map: Fzk project
© (c) Map data: Osm contributors
© (c) Contour data: U.S. Geological Survey or J. de Ferranti (free for 
research and private use)


And just to clarify again: the source file for the the option 
license-file and for the option copyright-file is the same file, it's 
only one file. And this is, according to my editors, properly utf8 :-(

Strange stuff... ;-)

Cheers
Patrik

On 04.12.2016 18:30, Steve 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 it look like on the device?

Cheers,
..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


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

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

2016-12-04 Thread Steve Ratcliffe 


OK I've realised that I am looking in the wrong place.  MapSource
is looking at the TDB file.  I've no idea where the device
gets the info from.

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

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

2016-12-04 Thread Patrik Brunner 
When checked via BaseCamp while the eTrex or the oregon 450t is hooked 
up to my machine:


 * Scrambled Characters for the special characters  shown only once
   (as the license-file thingy is missing on the device anyway)

© (c) Contour data: U.S. Geological Survey or J. de Ferranti (free for 
research and private use)

© (c) Map data: Osm contributors �� (Odbl)
© (c) Map: Fzk project �� (free for research and private use)

Directly on the device itself (tested both eTrex and oregon):

 * No additional stuff shown as in BaseCamp directly (the stuff that
   belongs to the map)
 * No special characters shown, looks like it cuts off everything on
   the line before the first special character.

It looks more or less (put together manually):

© (c) Map: Fzk project
© (c) Map data: Osm contributors
© (c) Contour data: U.S. Geological Survey or J. de Ferranti (free for 
research and private use)


And just to clarify again: the source file for the the option 
license-file and for the option copyright-file is the same file, it's 
only one file. And this is, according to my editors, properly utf8 :-(

Strange stuff... ;-)

Cheers
Patrik

On 04.12.2016 18:30, Steve 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 it look like on the device?

Cheers,
..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] mkgmap: problems with encoding file used with option --license-file

2016-12-04 Thread Steve Ratcliffe 

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 it look like on the device?

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

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

2016-12-04 Thread Patrik Brunner 
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 for
   research and private use)
   (c) Map data: OSM contributors �� (ODbl)
   (c) Map: FZK project äöüéèê (free for research and private use)
   (c) Map data: OSM contributors äöüéèê (ODbl)
   (c) Contour data: U.S. Geological Survey or J. de Ferranti (free for
   research and private use)

   (c) Map: FZK project �� (free for research and private use)
   Centre de Conf�rence et de Congr�s International (Salle municipale)
   centrale de Vianden (Station �lectrique)


The last two lines are what does not belong to it obviously.

Cheers
Patrik

On 04.12.2016 18:07, Steve Ratcliffe wrote:


Hi Patrik

OK, well try this out: http://files.mkgmap.org.uk/download/318/mkgmap.jar

This writes the copyright file text as labels encoded as cp1252
regardless of what the actual code-page in use is.  That is just
wierd but may work.  Also possible that only ascii characters are
allowed, but see how that goes.

..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] mkgmap: problems with encoding file used with option --license-file

2016-12-04 Thread Steve Ratcliffe 


Hi Patrik

OK, well try this out: http://files.mkgmap.org.uk/download/318/mkgmap.jar

This writes the copyright file text as labels encoded as cp1252
regardless of what the actual code-page in use is.  That is just
wierd but may work.  Also possible that only ascii characters are
allowed, but see how that goes.

..Steve


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

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

2016-12-04 Thread Patrik Brunner 

downloaded... thanks.

It looks as you have a version quite similar to the one in the mkgmap 
repo as it supports the same options. But with some different handling 
of file encodings.
Possibly an 'older' version or an adapted version of the mkgmap repo 
version. I can't tell you.


Verbose option: sounds like a confirmation for me if you want to be 
sure about the message on your end, just run it with verbose flag on a 
map built with mkgmap I would not be surprised if you get the same 
message too... ;-)


Saludos
Patrik

On 04.12.2016 17:37, Carlos Dávila wrote:

I don't use -v, 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 -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 Troxel wrote:

Steve Ratcliffe  writes:


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.

Yes, this seems a reasonable thing to do.

I would like to see this too.  I run mkgmap on a mac, and want to have
both a big .img to load directly and also gmapi format to load into
basecamp.


In the mkgmap code base there is a python program called
gmapi-builder.py in the scripts directory.

See also https://bitbucket.org/berteun/gmapibuilder/overview
and http://wiki.openstreetmap.org/wiki/Gmapibuilder.

This is a converter, but should work on all platforms with python
installed, or could be made to do so...
The first step is to verify that it works; then it should
be easy enough to implement within mkgmap itself.

For what it's worth, I have been using gmapibuilder with mkgmap for a
very long time.  The mod time on my gmapibuilder.py file is December
2009.  I have had essentially zero trouble. 


___
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] mkgmap: problems with encoding file used with option --license-file

2016-12-04 Thread Patrik Brunner 

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


I can't check how it was in earlier days regarding license and copyright 
information no real old files around anymore constantly running 
out of space here... ;-)


I guess it's fine to have it in 'proper' case as written in the files 
inside the license and copyright information, looks nicer. And the 
actual devices (what I could test) do definitely support it.
And I definitely prefer to unset the 'lower-case' option again if all 
runs fine without it.


Thanks
Patrik

On 04.12.2016 17:31, Steve Ratcliffe wrote:


Patrik


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


OK thanks that helps I will post something to try later.


-> lower-case option
I've double checked with older maps I was definitely building without
the --lower-case option and the map always showed proper case (capital
and lower case) names, preserving OSM style on my Garmin devices (at
least for the last few months... didn't/couldn't check back more).
Looking in BaseCamp at the license/copyright information I can say that
we had part in capitals and part in mixed cases, assuming that
copyright-message (I was using the message, not the copyright-file
option earlier) was in capital letters only.
The license-file part was before always in mixed cases as it should be.
And to make the statment complete: the codepage option was always used
and set.


In MapSource etc it will display in upper and lower case even though
the label in the map is all in uppercase.  It just capitalises the
first letter of each work and lower cases the rest.  So "OSM Road"
would be stored as "OSM ROAD" and displayed as "Osm Road".

All I can do is control what is actually put into the map, how any
particular device displays it is up to the device.


..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] Feature Request: mkgmap able to create gmap archive (BaseCamp)

2016-12-04 Thread Carlos Dávila 

I don't use -v, 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 -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 Troxel wrote:

Steve Ratcliffe  writes:


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.

Yes, this seems a reasonable thing to do.

I would like to see this too.  I run mkgmap on a mac, and want to have
both a big .img to load directly and also gmapi format to load into
basecamp.


In the mkgmap code base there is a python program called
gmapi-builder.py in the scripts directory.

See also https://bitbucket.org/berteun/gmapibuilder/overview
and http://wiki.openstreetmap.org/wiki/Gmapibuilder.

This is a converter, but should work on all platforms with python
installed, or could be made to do so...
The first step is to verify that it works; then it should
be easy enough to implement within mkgmap itself.

For what it's worth, I have been using gmapibuilder with mkgmap for a
very long time.  The mod time on my gmapibuilder.py file is December
2009.  I have had essentially zero trouble. 


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

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

2016-12-04 Thread Steve Ratcliffe 


Patrik


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


OK thanks that helps I will post something to try later.


-> lower-case option
I've double checked with older maps I was definitely building without
the --lower-case option and the map always showed proper case (capital
and lower case) names, preserving OSM style on my Garmin devices (at
least for the last few months... didn't/couldn't check back more).
Looking in BaseCamp at the license/copyright information I can say that
we had part in capitals and part in mixed cases, assuming that
copyright-message (I was using the message, not the copyright-file
option earlier) was in capital letters only.
The license-file part was before always in mixed cases as it should be.
And to make the statment complete: the codepage option was always used
and set.


In MapSource etc it will display in upper and lower case even though
the label in the map is all in uppercase.  It just capitalises the
first letter of each work and lower cases the rest.  So "OSM Road"
would be stored as "OSM ROAD" and displayed as "Osm Road".

All I can do is control what is actually put into the map, how any
particular device displays it is up to the device.


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

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

2016-12-04 Thread Patrik Brunner 

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 Troxel wrote:

Steve Ratcliffe  writes:


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.

Yes, this seems a reasonable thing to do.

I would like to see this too.  I run mkgmap on a mac, and want to have
both a big .img to load directly and also gmapi format to load into
basecamp.


In the mkgmap code base there is a python program called
gmapi-builder.py in the scripts directory.

See also https://bitbucket.org/berteun/gmapibuilder/overview
and http://wiki.openstreetmap.org/wiki/Gmapibuilder.

This is a converter, but should work on all platforms with python
installed, or could be made to do so...
The first step is to verify that it works; then it should
be easy enough to implement within mkgmap itself.

For what it's worth, I have been using gmapibuilder with mkgmap for a
very long time.  The mod time on my gmapibuilder.py file is December
2009.  I have had essentially zero trouble.
___
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] Feature Request: mkgmap able to create gmap archive (BaseCamp)

2016-12-04 Thread Greg Troxel 
Steve Ratcliffe  writes:

>> 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.
>
> Yes, this seems a reasonable thing to do.

I would like to see this too.  I run mkgmap on a mac, and want to have
both a big .img to load directly and also gmapi format to load into
basecamp.

> In the mkgmap code base there is a python program called
> gmapi-builder.py in the scripts directory.
>
> See also https://bitbucket.org/berteun/gmapibuilder/overview
> and http://wiki.openstreetmap.org/wiki/Gmapibuilder.
>
> This is a converter, but should work on all platforms with python
> installed, or could be made to do so...
> The first step is to verify that it works; then it should
> be easy enough to implement within mkgmap itself.

For what it's worth, I have been using gmapibuilder with mkgmap for a
very long time.  The mod time on my gmapibuilder.py file is December
2009.  I have had essentially zero trouble.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

2016-12-04 Thread Patrik Brunner 

Gracias Carlos,

I get following error when trying to download it:

You don't have permission to access /gmapi-builder.py on this server.

Saludos

Patrik

On 04.12.2016 16:21, Carlos Dávila wrote:
I've been using gmapi-builder.py for years within my tool chain 
without such block warning. I don't remember where I got it from nor 
when, file is dated February 2011. I have placed a copy of it at [1] 
in case you want to try it.

[1] http://mapas.alternativaslibres.es/gmapi-builder.py

El 04/12/16 a las 11:58, Steve Ratcliffe escribió:

Hi, thanks for testing. I believe you can ignore that error.

On 4 December 2016 10:38:27 GMT+00:00, Patrik Brunner 
 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 another Perimeter, Switzerland,
and
the same thing happens.

But as stated originally: I'm not sure how bad this error is as:

  * the image directory with these tbd file is useable in BaseCamp
  * the created gmap directory is usable in BaseCamp
  * the created gmapsupp.img out of the same source files is usable too

Either a misinterpretation of gmapi-builder.py or something which is
handled wrongly in mkgmap, but as it appears without doing too much
damage.
But that's just a rough guess from what I see from the outside. I'm

the wrong person to track that down to the root cause.

But I'm always willing and able to test and provide results.

Cheers
Patrik

On 04.12.2016 11:13, Thomas Morgenstern wrote:

In tdb file exists such block 0x54. And it must have 20 byte. in your
example i see only 18 byte ? Block 0x54 contains  CRC sum of the tdb
file ( without the 0x54 block) the crc is stored in byte 0x54+5,
0x54+12, 0x54+15, 0x54+20.

0x54+5=Int(nCRCSum / 16777216)  'vByteD

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,

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 mkgmap codebase version only.

The tool runs through and creates a loadable gmap directory for
BaseCamp (tested only on Windows).

But it also give out an 'error' or 'warning' about an unknown block,
possibly to be checked further when implementing in mkgmap:

 Unknown Block: 54, length: 20,
'\x00\x00\xf7\x00\x00\x00\x00\x00\x00j\x00\x00\x99\x00\x00\x00\x00`\x00\x00' 


Attached the complete command output ran with -v please ignore
the copyright/license output... the strange content is testing stuff
from another construction area, as you know... license information
and unicode  ;-)

Testing inside this construction area will be next on my list for
today...

Thanks and regards
Patrik

On 03.12.2016 23:26, Steve Ratcliffe wrote:

Hi


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.

Yes, this seems a reasonable thing to do.

In the mkgmap code base there is a python program called
gmapi-builder.py in the scripts directory.

See also https://bitbucket.org/berteun/gmapibuilder/overview
and http://wiki.openstreetmap.org/wiki/Gmapibuilder.

This is a converter, but should work on all platforms with python
installed, or could be made to do so...
The first step is to verify that it works; then it should
be easy enough to implement within mkgmap itself.

..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] Feature Request: mkgmap able to create gmap archive (BaseCamp)

2016-12-04 Thread Carlos Dávila 
I've been using gmapi-builder.py for years within my tool chain without 
such block warning. I don't remember where I got it from nor when, file 
is dated February 2011. I have placed a copy of it at [1] in case you 
want to try it.

[1] http://mapas.alternativaslibres.es/gmapi-builder.py

El 04/12/16 a las 11:58, Steve Ratcliffe escribió:

Hi, thanks for testing. I believe you can ignore that error.

On 4 December 2016 10:38:27 GMT+00:00, Patrik Brunner  
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 another Perimeter, Switzerland,
and
the same thing happens.

But as stated originally: I'm not sure how bad this error is as:

  * the image directory with these tbd file is useable in BaseCamp
  * the created gmap directory is usable in BaseCamp
  * the created gmapsupp.img out of the same source files is usable too

Either a misinterpretation of gmapi-builder.py or something which is
handled wrongly in mkgmap, but as it appears without doing too much
damage.
But that's just a rough guess from what I see from the outside. I'm

the wrong person to track that down to the root cause.

But I'm always willing and able to test and provide results.

Cheers
Patrik

On 04.12.2016 11:13, Thomas Morgenstern wrote:

In tdb file exists such block 0x54. And it must have 20 byte. in your
example i see only 18 byte ? Block 0x54 contains  CRC sum of the tdb
file ( without the 0x54 block) the crc is stored in byte 0x54+5,
0x54+12, 0x54+15, 0x54+20.

0x54+5=Int(nCRCSum / 16777216)  'vByteD

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,

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 mkgmap codebase version only.

The tool runs through and creates a loadable gmap directory for
BaseCamp (tested only on Windows).

But it also give out an 'error' or 'warning' about an unknown block,
possibly to be checked further when implementing in mkgmap:

 Unknown Block: 54, length: 20,


'\x00\x00\xf7\x00\x00\x00\x00\x00\x00j\x00\x00\x99\x00\x00\x00\x00`\x00\x00'

Attached the complete command output ran with -v please ignore
the copyright/license output... the strange content is testing stuff
from another construction area, as you know... license information
and unicode  ;-)

Testing inside this construction area will be next on my list for
today...

Thanks and regards
Patrik

On 03.12.2016 23:26, Steve Ratcliffe wrote:

Hi


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.

Yes, this seems a reasonable thing to do.

In the mkgmap code base there is a python program called
gmapi-builder.py in the scripts directory.

See also https://bitbucket.org/berteun/gmapibuilder/overview
and http://wiki.openstreetmap.org/wiki/Gmapibuilder.

This is a converter, but should work on all platforms with python
installed, or could be made to do so...
The first step is to verify that it works; then it should
be easy enough to implement within mkgmap itself.

..Steve


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

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

2016-12-04 Thread Patrik Brunner 

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 checked with older maps I was definitely building without 
the --lower-case option and the map always showed proper case (capital 
and lower case) names, preserving OSM style on my Garmin devices (at 
least for the last few months... didn't/couldn't check back more).
Looking in BaseCamp at the license/copyright information I can say that 
we had part in capitals and part in mixed cases, assuming that 
copyright-message (I was using the message, not the copyright-file 
option earlier) was in capital letters only.

The license-file part was before always in mixed cases as it should be.
And to make the statment complete: the codepage option was always used 
and set.



Yes, preserving case for license-file and copyright-file (as well as 
copyright-message) would be great I would prefer not having to 
change the option lower-case while building the map, just to make sure 
we don't screw up stuff for old devices out there... ;-)


Looks like we're getting nearer to the real problem and to the 
solution great work, many thanks.


Cheers
Patrik

On 04.12.2016 14:55, Steve Ratcliffe wrote:


Hi Patrik


as promised here the outcome from the (hopefully) proper testing...


Great, so we only seem to have a remaining problem with unicode and the
copyright file.


That leaves up two things/questions:

  * I think copyright-file needs to be fixed also as this is the only
one being displayed on the GPS Device, correct ?


OK this is strange as the copyright file is just converted
into normal labels just like everything else on the map like
street names etc.  It was the licence file that was different.

I will take another look as I may have missed something there.

Can you tell me what characters you do see instead?


  * question: the description of the option --lower-case says that lower
case characters aren't displayed properly on most devices. On mine
(etrex30, oregon 450t, monterra) I couldn't find any difference in
the map, this option seems to affect only license and copyright
files ? Do I miss something ? Is it dangerous to set this option for
having a nice license as I might loose support for some devices ?


Yes, the --lower-case should affect the map; it leaves
names with the same case as they appear in OSM input file in the map.
That is as long as you are using one code-page option, without that
you get an ascii uppercase only format.

That comment in the help for --lower-case is out of date now.
When it was written, most or all hand held devices then available
could not display rotated lowercase text.  Horizontal text was OK.
Maybe even earlier devices couldn't display lower case text at all,
I'm not sure.

(eg. See the image in this post 
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/007667.html)


I will try to preserve the case of the text, after all if you want or
need the licence text to be in upper case you can just write it that
way in the file.

..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] mkgmap: problems with encoding file used with option --license-file

2016-12-04 Thread Steve Ratcliffe 


Hi Patrik


as promised here the outcome from the (hopefully) proper testing...


Great, so we only seem to have a remaining problem with unicode and the
copyright file.


That leaves up two things/questions:

  * I think copyright-file needs to be fixed also as this is the only
one being displayed on the GPS Device, correct ?


OK this is strange as the copyright file is just converted
into normal labels just like everything else on the map like
street names etc.  It was the licence file that was different.

I will take another look as I may have missed something there.

Can you tell me what characters you do see instead?


  * question: the description of the option --lower-case says that lower
case characters aren't displayed properly on most devices. On mine
(etrex30, oregon 450t, monterra) I couldn't find any difference in
the map, this option seems to affect only license and copyright
files ? Do I miss something ? Is it dangerous to set this option for
having a nice license as I might loose support for some devices ?


Yes, the --lower-case should affect the map; it leaves
names with the same case as they appear in OSM input file in the map.
That is as long as you are using one code-page option, without that
you get an ascii uppercase only format.

That comment in the help for --lower-case is out of date now.
When it was written, most or all hand held devices then available
could not display rotated lowercase text.  Horizontal text was OK.
Maybe even earlier devices couldn't display lower case text at all,
I'm not sure.

(eg. See the image in this post 
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/007667.html)


I will try to preserve the case of the text, after all if you want or
need the licence text to be in upper case you can just write it that
way in the file.

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

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

2016-12-04 Thread Patrik Brunner 

Steve,

as promised here the outcome from the (hopefully) proper testing...

Tests performed with maps created on Windows:

 * licence-file option: Check in Basecamp (Windows):
   now ok if I build cp1252 or unicode map, thumbs up !
 * lower-case option:
   if this option is set then I get proper capital and lower-case
   letters in shown license, if not set the it shows all capital
   letters... I haven't found any other differences in the map,
   Basecamp shows proper names on map.
 * copyright-file option: Check in BaseCamp (Windows):
   still shows scrambled characters in unicode map but also still ok in
   cp1252 maps

Additional tests performed with map created on Linux and final gmap 
checked on BaseCamp (Windows):


 * created unicode map and cp1252 map
 * on cp1252 map: both copyright-file and license-file output looks
   good (as expected)
 * on unicode map: consistent behaviour as on windows: license-file
   output correct, copyright-file output scrambled

That leaves up two things/questions:

 * I think copyright-file needs to be fixed also as this is the only
   one being displayed on the GPS Device, correct ?
 * question: the description of the option --lower-case says that lower
   case characters aren't displayed properly on most devices. On mine
   (etrex30, oregon 450t, monterra) I couldn't find any difference in
   the map, this option seems to affect only license and copyright
   files ? Do I miss something ? Is it dangerous to set this option 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 anything up on my end I would guess:


  * it looks like you found the correct hook
  * when building unicode map either copyright-file or license-file
result is now correct (which one will show further testing
tomorrow, assuming license-file), the other one ist still 'screwed
up' (allthough I'm not sure if I really have to/want to set both)
  * non-unicode map (cp1252) still seems to build fine
(license/copyright wise)
  * One thing to mention which caught my attention: it looks like I
now have only capital letters when checking with BaseCamp...
before I had also lower case letters (at least in one of the two
options copyright-file and license-file) needs more
investigations from my end also.

I'll do proper testing (hopefully) tomorrow and will let you know the 
outcome. I've to check the result also on the Garmin Devices directly 
(gmapsupp.im)... hopefully the result is still the same as before...


Thanks again.

Cheers
Patrik

On 03.12.2016 21:07, Steve Ratcliffe wrote:

Hi Patrik


where you able to investigate some more ? Is there another build I
can/have to try it with ?


As it happens I just discovered something today.  There is no 
encoding done for the copyright info before the TRE section data.


Patch attached to fix this and pre-made jar file at: 
http://files.mkgmap.org.uk/download/317/mkgmap.jar


Cheers,
..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] Feature Request: mkgmap able to create gmap archive (BaseCamp)

2016-12-04 Thread Steve Ratcliffe 
Hi, thanks for testing. I believe you can ignore that error.

On 4 December 2016 10:38:27 GMT+00:00, Patrik Brunner  
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 another Perimeter, Switzerland,
>and 
>the same thing happens.
>
>But as stated originally: I'm not sure how bad this error is as:
>
>  * the image directory with these tbd file is useable in BaseCamp
>  * the created gmap directory is usable in BaseCamp
>  * the created gmapsupp.img out of the same source files is usable too
>
>Either a misinterpretation of gmapi-builder.py or something which is 
>handled wrongly in mkgmap, but as it appears without doing too much
>damage.
>But that's just a rough guess from what I see from the outside. I'm
>
>the wrong person to track that down to the root cause.
>
>But I'm always willing and able to test and provide results.
>
>Cheers
>Patrik
>
>On 04.12.2016 11:13, Thomas Morgenstern wrote:
>>
>> In tdb file exists such block 0x54. And it must have 20 byte. in your
>
>> example i see only 18 byte ? Block 0x54 contains  CRC sum of the tdb 
>> file ( without the 0x54 block) the crc is stored in byte 0x54+5, 
>> 0x54+12, 0x54+15, 0x54+20.
>>
>> 0x54+5=Int(nCRCSum / 16777216)  'vByteD
>>
>> 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,
>>>
>>> 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 mkgmap codebase version only.
>>>
>>> The tool runs through and creates a loadable gmap directory for 
>>> BaseCamp (tested only on Windows).
>>>
>>> But it also give out an 'error' or 'warning' about an unknown block,
>
>>> possibly to be checked further when implementing in mkgmap:
>>>
>>> Unknown Block: 54, length: 20,
>>>
>'\x00\x00\xf7\x00\x00\x00\x00\x00\x00j\x00\x00\x99\x00\x00\x00\x00`\x00\x00'
>>>
>>> Attached the complete command output ran with -v please ignore 
>>> the copyright/license output... the strange content is testing stuff
>
>>> from another construction area, as you know... license information 
>>> and unicode  ;-)
>>>
>>> Testing inside this construction area will be next on my list for 
>>> today...
>>>
>>> Thanks and regards
>>> Patrik
>>>
>>> On 03.12.2016 23:26, Steve Ratcliffe wrote:
 Hi

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

 Yes, this seems a reasonable thing to do.

 In the mkgmap code base there is a python program called
 gmapi-builder.py in the scripts directory.

 See also https://bitbucket.org/berteun/gmapibuilder/overview
 and http://wiki.openstreetmap.org/wiki/Gmapibuilder.

 This is a converter, but should work on all platforms with python
 installed, or could be made to do so...
 The first step is to verify that it works; then it should
 be easy enough to implement within mkgmap itself.

 ..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
>>
>>
>>
>> ___
>> 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] Feature Request: mkgmap able to create gmap archive (BaseCamp)

2016-12-04 Thread Patrik Brunner 

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 another Perimeter, Switzerland, and 
the same thing happens.


But as stated originally: I'm not sure how bad this error is as:

 * the image directory with these tbd file is useable in BaseCamp
 * the created gmap directory is usable in BaseCamp
 * the created gmapsupp.img out of the same source files is usable too

Either a misinterpretation of gmapi-builder.py or something which is 
handled wrongly in mkgmap, but as it appears without doing too much damage.
But that's just a rough guess from what I see from the outside. I'm 
the wrong person to track that down to the root cause.


But I'm always willing and able to test and provide results.

Cheers
Patrik

On 04.12.2016 11:13, Thomas Morgenstern wrote:


In tdb file exists such block 0x54. And it must have 20 byte. in your 
example i see only 18 byte ? Block 0x54 contains  CRC sum of the tdb 
file ( without the 0x54 block) the crc is stored in byte 0x54+5, 
0x54+12, 0x54+15, 0x54+20.


0x54+5=Int(nCRCSum / 16777216)  'vByteD

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,

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 mkgmap codebase version only.


The tool runs through and creates a loadable gmap directory for 
BaseCamp (tested only on Windows).


But it also give out an 'error' or 'warning' about an unknown block, 
possibly to be checked further when implementing in mkgmap:


Unknown Block: 54, length: 20,
'\x00\x00\xf7\x00\x00\x00\x00\x00\x00j\x00\x00\x99\x00\x00\x00\x00`\x00\x00'

Attached the complete command output ran with -v please ignore 
the copyright/license output... the strange content is testing stuff 
from another construction area, as you know... license information 
and unicode  ;-)


Testing inside this construction area will be next on my list for 
today...


Thanks and regards
Patrik

On 03.12.2016 23:26, Steve Ratcliffe wrote:

Hi


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.


Yes, this seems a reasonable thing to do.

In the mkgmap code base there is a python program called
gmapi-builder.py in the scripts directory.

See also https://bitbucket.org/berteun/gmapibuilder/overview
and http://wiki.openstreetmap.org/wiki/Gmapibuilder.

This is a converter, but should work on all platforms with python
installed, or could be made to do so...
The first step is to verify that it works; then it should
be easy enough to implement within mkgmap itself.

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




___
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] Feature Request: mkgmap able to create gmap archive (BaseCamp)

2016-12-04 Thread Thomas Morgenstern 
In tdb file exists such block 0x54. And it must have 20 byte. in your 
example i see only 18 byte ? Block 0x54 contains  CRC sum of the tdb 
file ( without the 0x54 block) the crc is stored in byte 0x54+5, 
0x54+12, 0x54+15, 0x54+20.


0x54+5=Int(nCRCSum / 16777216)  'vByteD

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,

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 mkgmap codebase version only.


The tool runs through and creates a loadable gmap directory for 
BaseCamp (tested only on Windows).


But it also give out an 'error' or 'warning' about an unknown block, 
possibly to be checked further when implementing in mkgmap:


Unknown Block: 54, length: 20,
'\x00\x00\xf7\x00\x00\x00\x00\x00\x00j\x00\x00\x99\x00\x00\x00\x00`\x00\x00'

Attached the complete command output ran with -v please ignore the 
copyright/license output... the strange content is testing stuff from 
another construction area, as you know... license information and 
unicode  ;-)


Testing inside this construction area will be next on my list for today...

Thanks and regards
Patrik

On 03.12.2016 23:26, Steve Ratcliffe wrote:

Hi


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.


Yes, this seems a reasonable thing to do.

In the mkgmap code base there is a python program called
gmapi-builder.py in the scripts directory.

See also https://bitbucket.org/berteun/gmapibuilder/overview
and http://wiki.openstreetmap.org/wiki/Gmapibuilder.

This is a converter, but should work on all platforms with python
installed, or could be made to do so...
The first step is to verify that it works; then it should
be easy enough to implement within mkgmap itself.

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


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

Re: [mkgmap-dev] Size checks in splitter

2016-12-04 Thread Gerd Petermann 
See splitter r487 in the refactoring2 branch.


Von: mkgmap-dev  im Auftrag von Steve 
Sgalowski 
Gesendet: Sonntag, 4. Dezember 2016 10:51:47
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Size checks in splitter

it does to me , when i use a 3rd party program , that uses your files to split  
and combine

but ok gerd I but out and just use the program and force it as always .

Stephen


On Sun, Dec 4, 2016 at 7:46 PM, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:

Hi Stephen,


please explain I don't see how the suggested change in splitter is related to 
this.


Gerd


Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Steve Sgalowski 
mailto:steve.sgalow...@gmail.com>>
Gesendet: Sonntag, 4. Dezember 2016 10:36:02
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Size checks in splitter

when splitting Australia in the osm file of 7 gb in size , that would be 
usefull, as i set the max nodes to 90,000 to make smaller tiles as i get  
frequently , that there is not enough room in a single gmapsupp.img file to 
hold all the data .

Stephen


On Sun, Dec 4, 2016 at 7:28 PM, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:

Hi all,


years ago we added a check in splitter r251 to make sure that it doesn't write 
extremely large tiles.

See

http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q1/013611.html

and

http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q4/015707.html


In short: The problem is that the precomp-sea option will add a huge amout of 
sea polygons to such a tile,

another problem is that the bounds option loads a huge amount of data.


I've now noticed that this check might not be useful if you use splitter to 
split a large file into a few smaller tiles,

esp. the whole planet with num-tiles=2.

I'd like to skip this check when

a) --num-tiles is used

b) --max-nodes value is large, e.g. higher than 10.000.000


Another option would be to add a new option like --skip-size-check.


What do you think?

Gerd



___
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] Size checks in splitter

2016-12-04 Thread Steve Sgalowski 
it does to me , when i use a 3rd party program , that uses your files to
split  and combine

but ok gerd I but out and just use the program and force it as always .

Stephen


On Sun, Dec 4, 2016 at 7:46 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Stephen,
>
>
> please explain I don't see how the suggested change in splitter is related
> to this.
>
>
> Gerd
> --
> *Von:* mkgmap-dev  im Auftrag von
> Steve Sgalowski 
> *Gesendet:* Sonntag, 4. Dezember 2016 10:36:02
> *An:* Development list for mkgmap
> *Betreff:* Re: [mkgmap-dev] Size checks in splitter
>
> when splitting Australia in the osm file of 7 gb in size , that would be
> usefull, as i set the max nodes to 90,000 to make smaller tiles as i get
>  frequently , that there is not enough room in a single gmapsupp.img file
> to hold all the data .
>
> Stephen
>
>
> On Sun, Dec 4, 2016 at 7:28 PM, Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
>
>> Hi all,
>>
>>
>> years ago we added a check in splitter r251 to make sure that it doesn't
>> write extremely large tiles.
>>
>> See
>> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q1/013611.html
>>
>> and
>>
>> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q4/015707.html
>>
>>
>> In short: The problem is that the precomp-sea option will add a huge
>> amout of sea polygons to such a tile,
>>
>> another problem is that the bounds option loads a huge amount of data.
>>
>>
>> I've now noticed that this check might not be useful if you use splitter
>> to split a large file into a few smaller tiles,
>>
>> esp. the whole planet with num-tiles=2.
>>
>> I'd like to skip this check when
>>
>> a) --num-tiles is used
>>
>> b) --max-nodes value is large, e.g. higher than 10.000.000
>>
>>
>> Another option would be to add a new option like --skip-size-check.
>>
>>
>> What do you think?
>>
>> Gerd
>>
>>
>>
>>
>> ___
>> 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] Size checks in splitter

2016-12-04 Thread Gerd Petermann 
Hi Stephen,


please explain I don't see how the suggested change in splitter is related to 
this.


Gerd


Von: mkgmap-dev  im Auftrag von Steve 
Sgalowski 
Gesendet: Sonntag, 4. Dezember 2016 10:36:02
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Size checks in splitter

when splitting Australia in the osm file of 7 gb in size , that would be 
usefull, as i set the max nodes to 90,000 to make smaller tiles as i get  
frequently , that there is not enough room in a single gmapsupp.img file to 
hold all the data .

Stephen


On Sun, Dec 4, 2016 at 7:28 PM, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:

Hi all,


years ago we added a check in splitter r251 to make sure that it doesn't write 
extremely large tiles.

See

http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q1/013611.html

and

http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q4/015707.html


In short: The problem is that the precomp-sea option will add a huge amout of 
sea polygons to such a tile,

another problem is that the bounds option loads a huge amount of data.


I've now noticed that this check might not be useful if you use splitter to 
split a large file into a few smaller tiles,

esp. the whole planet with num-tiles=2.

I'd like to skip this check when

a) --num-tiles is used

b) --max-nodes value is large, e.g. higher than 10.000.000


Another option would be to add a new option like --skip-size-check.


What do you think?

Gerd



___
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] Feature Request: mkgmap able to create gmap archive (BaseCamp)

2016-12-04 Thread Patrik Brunner 

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 
mkgmap codebase version only.


The tool runs through and creates a loadable gmap directory for BaseCamp 
(tested only on Windows).


But it also give out an 'error' or 'warning' about an unknown block, 
possibly to be checked further when implementing in mkgmap:


   Unknown Block: 54, length: 20,
   '\x00\x00\xf7\x00\x00\x00\x00\x00\x00j\x00\x00\x99\x00\x00\x00\x00`\x00\x00'

Attached the complete command output ran with -v please ignore the 
copyright/license output... the strange content is testing stuff from 
another construction area, as you know... license information and 
unicode  ;-)


Testing inside this construction area will be next on my list for today...

Thanks and regards
Patrik

On 03.12.2016 23:26, Steve Ratcliffe wrote:

Hi


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.


Yes, this seems a reasonable thing to do.

In the mkgmap code base there is a python program called
gmapi-builder.py in the scripts directory.

See also https://bitbucket.org/berteun/gmapibuilder/overview
and http://wiki.openstreetmap.org/wiki/Gmapibuilder.

This is a converter, but should work on all platforms with python
installed, or could be made to do so...
The first step is to verify that it works; then it should
be easy enough to implement within mkgmap itself.

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


/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/gmapi-builder/gmapi-builder.py
 -v -o 
/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/install/Freizeitkarte_LUX_fr
 -t Freizeitkarte_LUX.tdb -s 6442.TYP -i Freizeitkarte_LUX.mdx -m 
Freizeitkarte_LUX_mdr.img -b Freizeitkarte_LUX.img *.img
Unknown Block: 54, length: 20, 
'\x00\x00\xf3\x00\x00\x00\x00\x00\x00\xa2\x00\x00h\x00\x00\x00\x00;\x00\x00'
TDB Version:4.07
Product ID: 1
Family ID:  6442
Map Series: Freizeitkarte_LUX
Map Family: Freizeitkarte_LUX
Product Version:16.12

Copyright:  (C) MAP: FZK PROJECT ÄÖÜÉÈÊ (FREE FOR RESEARCH AND PRIVATE 
USE)
(C) MAP DATA: OSM CONTRIBUTORS ÄÖÜÉÈÊ
(C) CONTOUR DATA: U.S. GEOLOGICAL SURVEY OR J. DE FERRANTI

Copyright:
Copyright:  (C) MAP: FZK PROJECT ÄÖÜÉÈÊ (FREE FOR RESEARCH AND PRIVATE 
USE)
Copyright:  (C) MAP DATA: OSM CONTRIBUTORS ÄÖÜÉÈÊ
Copyright:  (C) CONTOUR DATA: U.S. GEOLOGICAL SURVEY OR J. DE FERRANTI

Trademark:  Test preview map

Overview map:
Map Number: 6442
Parent Map: 0
Latitude North: 50.1855
Longitude East:  6.5479
Latitude South: 49.4385
Longitude West:  5.7129
Description:Overview Map

Processing 64420001.img
Processing 64420002.img
Processing 64420003.img
Processing Freizeitkarte_LUX.img
Processing Freizeitkarte_LUX_mdr.img
MDR file
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Size checks in splitter

2016-12-04 Thread Steve Sgalowski 
when splitting Australia in the osm file of 7 gb in size , that would be
usefull, as i set the max nodes to 90,000 to make smaller tiles as i get
 frequently , that there is not enough room in a single gmapsupp.img file
to hold all the data .

Stephen


On Sun, Dec 4, 2016 at 7:28 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi all,
>
>
> years ago we added a check in splitter r251 to make sure that it doesn't
> write extremely large tiles.
>
> See
> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q1/013611.html
>
> and
>
> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q4/015707.html
>
>
> In short: The problem is that the precomp-sea option will add a huge amout
> of sea polygons to such a tile,
>
> another problem is that the bounds option loads a huge amount of data.
>
>
> I've now noticed that this check might not be useful if you use splitter
> to split a large file into a few smaller tiles,
>
> esp. the whole planet with num-tiles=2.
>
> I'd like to skip this check when
>
> a) --num-tiles is used
>
> b) --max-nodes value is large, e.g. higher than 10.000.000
>
>
> Another option would be to add a new option like --skip-size-check.
>
>
> What do you think?
>
> Gerd
>
>
>
>
> ___
> 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] Size checks in splitter

2016-12-04 Thread Gerd Petermann 
Hi all,


years ago we added a check in splitter r251 to make sure that it doesn't write 
extremely large tiles.

See

http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q1/013611.html

and

http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q4/015707.html


In short: The problem is that the precomp-sea option will add a huge amout of 
sea polygons to such a tile,

another problem is that the bounds option loads a huge amount of data.


I've now noticed that this check might not be useful if you use splitter to 
split a large file into a few smaller tiles,

esp. the whole planet with num-tiles=2.

I'd like to skip this check when

a) --num-tiles is used

b) --max-nodes value is large, e.g. higher than 10.000.000


Another option would be to add a new option like --skip-size-check.


What do you think?

Gerd


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