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 *.gmapi folder and create directly *.gmap. As I understand gmapi is a container for bundling unlock code with a map, which could be useful when moving maps between computers, but not for creating a new map.

Hi

java -Xmx1536M -Dfile.encoding=UTF-8 -jar D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/mkgmap.gmapi/mkgmap.jar --max-jobs=2 --license-file=Freizeitkarte_LUX.license --index --gmapi - -product-id=1 --family-id=6442 --family-name="Freizeitkarte_LUX 16.12" --series-name="Freizeitkarte_LUX 16.12" --description="Freizeitkarte_LUX 16.12" --overview-mapnumber=64420000 --product-version=1612 6442*.img 6442.TYP Time started: Mon Dec 05 21:45:21 CET 2016 Number of MapFailedExceptions: 0 WARNING: input files have different code pages

You need a --latin1 or --code-page=1252 I may have some tricky code in the gmapsupp case which guesses the correct code-page from the first file or something, so maybe it wasn't needed before. ..Steve

On 05/12/16 19:32, Patrik Brunner wrote:

I'm happy to test the actual version also.... is there a prebuilt jar file ?

Yes on the main mkgmap download page, near the bottom. In fact you can the latest version of any branch (where gmapi is the branch in this case) like this: http://www.mkgmap.org.uk/download/mkgmap-gmapi-latest.zip or http://www.mkgmap.org.uk/download/mkgmap-gmapi-latest.jar http://www.mkgmap.org.uk/download/mkgmap-gmapi-latest.tar.gz depending on what you want.

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 around after the creation, so I just have to grab the correct on. But I can't say if the container around it is of any use for special cases. Cheers Patrik On 05.12.2016 22:45, Steve Ratcliffe wrote:

On 05/12/16 16:14, Andrzej Popowski wrote:

...

My suggestion is to drop *.gmapi folder and create directly *.gmap. As I understand gmapi is a container for bundling unlock code with a map, which could be useful when moving maps between computers, but not for creating a new map.

I've never used the format before, so you can just use a .gmap instead of the .gmapi then?

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

Hi

I would prefer having the top directory named differently/choosable.... why not using the basemap name ? or just a free choosable name ?

OK I thought this might merit some discussion. The top level directory is currently controlled by --overview-mapname. So it is the same as the basemap name. It should, based on looking at what the Garmin MapConverter does, use family-name instead. The scripts/gmapi-builder.py script uses the product name, which would not work in the case where there is more than one product in a family. I don't know if anyone actually does that.

And: to have another convincing reason: Official City Navigator Europe NTU 2016.30 is using the basename 'CNEuroNTU_2016_30' for the gmap folder and subcomponents.

What is the family name for that map? It should be in the first <Name> element in the Info.xml file. Does it have spaces or underscores or is different altogether? ..Steve

Steve, indeed the names are absolutely correct when calling with --overview-mapname. Checking the outcoming directory structure aswell as the xml file shows all fine regarding file names: <?xml version="1.0" encoding="UTF-8"?> <MapProduct xmlns="http://www.garmin.com/xmlschemas/MapProduct/v1"> <Name>Freizeitkarte_LUX 16.12</Name> <DataVersion>100</DataVersion> <DataFormat>Original</DataFormat> <ID>6442</ID> <IDX>Freizeitkarte_LUX.mdx</IDX> <MDR>Freizeitkarte_LUX_mdr</MDR> <TYP>6442.TYP</TYP> <SubProduct> <Name>Freizeitkarte_LUX 16.12</Name> <ID>1</ID> <BaseMap>Freizeitkarte_LUX</BaseMap> <TDB>Freizeitkarte_LUX.tdb</TDB> <Directory>Product1</Directory> </SubProduct> </MapProduct> I'm just wondering about DataVersion being 100 eventhough I call mkgmap with --product-version="1612". Shouldn't that version go into that DataVersion also ? A gmap archive structure created with jmc_cli does fill DataVersion with the 'correct' number, btw. As promised here the xml file from the City Navigator: Info.xml <?xml version="1.0" encoding="utf-8"?> <MapProduct xmlns="http://www.garmin.com/xmlschemas/MapProduct/v1"> <Name>City Navigator Europe NTU 2016.30</Name> <InstallationID>1</InstallationID> <DataVersion>1930</DataVersion> <DataFormat>NT</DataFormat> <ID>4037</ID> <IDX>CNEuroNTU_2016_30.mdx</IDX> <MDR>CNEuroNTU_2016_30_mdr</MDR> <TRF>CNEuroNTU_2016_30_trf.trf</TRF> <TYP>I0000FC5.TYP</TYP> <SubProduct> <Name>City Navigator Europe NTU 2016.3</Name> <ID>1</ID> <BaseMap>CNEuroNTU_2016_30</BaseMap> <TDB>CNEuroNTU_2016_30.tdb</TDB> <Directory>Product1</Directory> <Notice>eula.txt</Notice> <MapLogosPath>Logos</MapLogosPath> </SubProduct> </MapProduct> Info_v2.xml: <?xml version="1.0" encoding="utf-8"?> <MapProduct xmlns="http://www.garmin.com/xmlschemas/MapProduct/v2"> <Name>City Navigator Europe NTU 2016.30</Name> <InstallationID>1</InstallationID> <DataVersion>1930</DataVersion> <DataFormat>NT</DataFormat> <ID>4037</ID> <Files> <File id="IDX">CNEuroNTU_2016_30.mdx</File> <File id="MDR">CNEuroNTU_2016_30_mdr</File> <File id="TRF">CNEuroNTU_2016_30_trf.trf</File> <File id="TYP">I0000FC5.TYP</File> </Files> <SubProduct> <Name>City Navigator Europe NTU 2016.3</Name> <ID>1</ID> <BaseMap>CNEuroNTU_2016_30</BaseMap> <Directory>Product1</Directory> <Files> <File id="TDB">CNEuroNTU_2016_30.tdb</File> <File id="NoticeUtf8">eula.txt</File> </Files> </SubProduct> <MapLogosPath>Logos</MapLogosPath> </MapProduct> Thanks 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 Navigator: I'm quite sure it didn't contain spaces, but I'll doublecheck when I have access to the machine with the City Navigator installed and send you the complete content of the XML file.... also latest tomorrow. Cheers Patrik *Gesendet:* Mittwoch, 14. Dezember 2016 um 23:03 Uhr *Von:* "Steve Ratcliffe" <steve@parabola.me.uk> *An:* "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk> *Betreff:* Re: [mkgmap-dev] Adding the gmapi format.

Hi

...

I would prefer having the top directory named differently/choosable.... why not using the basemap name ? or just a free choosable name ?

OK I thought this might merit some discussion.

The top level directory is currently controlled by --overview-mapname. So it is the same as the basemap name. It should, based on looking at what the Garmin MapConverter does, use family-name instead.

The scripts/gmapi-builder.py script uses the product name, which would not work in the case where there is more than one product in a family. I don't know if anyone actually does that.

...

And: to have another convincing reason: Official City Navigator Europe NTU 2016.30 is using the basename 'CNEuroNTU_2016_30' for the gmap folder and subcomponents.

What is the family name for that map? It should be in the first <Name> element in the Info.xml file. Does it have spaces or underscores or is different altogether?

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

perfect: ... <DataVersion>1612</DataVersion> ... 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 tests until now on windows, I will also do some linux testing of this branch. Thanks for the quick fix of this... Cheers Patrik On 15.12.2016 21:57, Steve Ratcliffe wrote:

Hi Patrik

...

I'm just wondering about DataVersion being 100 eventhough I call mkgmap with --product-version="1612". Shouldn't that version go into that DataVersion also ? A gmap archive structure created with jmc_cli does fill DataVersion with the 'correct' number, btw.

Yes you are correct. I have added support for --product-version.

This means that it should really be called --family-version using our as you can't specify one for each product.

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

Steve, one last thing to mention: It's probably obvious, clear and will be resolved when merging back to trunk... but nevertheless I want to mention it quickly here: * the gmapi branch is not yet unicode save regarding license and copyright file. I've noticed this while doing some final '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 aswell as on BaseCamp for Macintosh... ... and it all looks fine.

Besides that I've built an ever bigger map with 'old' r3727 on Windows and tested it on Windows BaseCamp only. ... and it all looks fine

The same big map and a few smaller ones were built again or 'new' r3729 and tested on Windows BaseCamp only. ... and it all looks fine.

I would consider the branch, at least from my perspective, ready for production... ;-)

Many thanks for implementing it that quick and easy. Cheers Patrik

On 15.12.2016 22:10, Patrik Brunner wrote:

...

perfect: ... <DataVersion>1612</DataVersion> ...

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 tests until now on windows, I will also do some linux testing of this branch.

Thanks for the quick fix of this...

Cheers Patrik

On 15.12.2016 21:57, Steve Ratcliffe wrote:

...

Hi Patrik

...

I'm just wondering about DataVersion being 100 eventhough I call mkgmap with --product-version="1612". Shouldn't that version go into that DataVersion also ? A gmap archive structure created with jmc_cli does fill DataVersion with the 'correct' number, btw.

Yes you are correct. I have added support for --product-version.

This means that it should really be called --family-version using our as you can't specify one for each product.

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

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... ... and I might have found an additional issue regarding --product-version and the gmapsupp output. ;-) But I will have to test this a bit more before really raising the issue, could also be that the problem stays on my side... ;-) Thanks again and cheers Patrik On 18.12.2016 17:01, Steve Ratcliffe wrote:

Hi Patrik

...

It's probably obvious, clear and will be resolved when merging back to trunk... but nevertheless I want to mention it quickly here:

* the gmapi branch is not yet unicode save regarding license and copyright file.

Yes, they should be completely independent. When both are merged the gmapi format should acquire the Unicode fixes.

But now they are both merged so you can test if that is really true ;)

Thanks for your testing and problem finding throughout.

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

Hi Steve,

What is the family name for that map? It should be in the first <Name> element in the Info.xml file. Does it have spaces or underscores or is different altogether?

Folder for CN EU 2017.20 is "City Navigator Europe NTU 2017.20.gmap", with spaces. Name inside info.xml is the same: <Name>City Navigator Europe NTU 2017.20</Name> See this link: http://www8.garmin.com/xmlschemas/index.jsp Each manifest there shows layout of a City Navigator map. You can actually download these maps, basing on links from manifest, Garmin left them open. -- Best regards, Andrzej

Andrzej Popowski <popej@poczta.onet.pl> writes:

gmapi is used to install maps on MacOS. This extension is associated with Garmin programs, but I think gmap works the same. I don't know any use for gmapi on Windows, all you need on Windows is gmap folder.

I thought gmapi was normal, but I'm using basecamp on OS X to view mkgmap-generated maps. I put them in GMAPI, and $ ls -lR GMAPI total 0 drwxr-xr-x+ 3 gdt staff 102 Nov 20 12:01 OSM_gdt_series.gmapi GMAPI/OSM_gdt_series.gmapi: total 0 drwxr-xr-x+ 7 gdt staff 238 Nov 20 12:01 OSM_gdt_series.gmap GMAPI/OSM_gdt_series.gmapi/OSM_gdt_series.gmap: total 36 -rw-r--r--+ 1 gdt staff 1322 Nov 20 12:01 63240000.mdx drwxr-xr-x+ 4 gdt staff 136 Nov 20 12:01 63240000_mdr -rw-r--r--+ 1 gdt staff 26883 Nov 20 12:01 CFMaster.TYP -rw-r--r--+ 1 gdt staff 552 Nov 20 12:01 Info.xml drwxr-xr-x+ 113 gdt staff 3842 Nov 20 12:01 OSMTiles I have always done "open GMAPI/OSM_gdt_series.gmapi" to start mapmanager, but "open GMAPI/OSM_gdt_series.gmapi/OSM_gdt_series.gmap" worked also. So I don't think the outer container is needed. Plus, this is easy to add back if we figure out later that it's useful. But I don't think its presence hurts anything.