<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hey Harri,</p>
<p>do not retire an old friend easily. <br>
</p>
<p>Re-reading my mail, I may have falsely assumed things as given
and been to brief in places. <br>
Rereading yours carefully, I think, I see potential tripping
points now.</p>
<p>Why not give it one last fight?</p>
<p>Nevertheless, the following is based on trial 'n error only
(quite old trials even, from when I started to experiment with
mkgmap), but I manually went through all the motions again right
now and the merged maps load well. If things are misinterpreted
along the way, please everybody pipe in .<br>
</p>
<p>As for the potential tripping points:</p>
<ol>
<li>Your first mail reads: "I'm generating multiple files [.imgs],
all with different family-id, product-id, mapname and map
description."<br>
But then your second mail details: "At the moment I have tiles,
use mkgmap with some style and then run mkgmap with another
style to make overlay like arrows for oneway streets and I need
to combine that kind of results." <br>
I'm assuming you start with some Geofabric file, maybe use
osmconvert with a bbox or polygone and then splitter, to get the
tiles. One argument of splitter should be --mapid. I typically
use --mapid=FID0001, e.g. --mapid=64100001 for a map wit FID
6410. These mapids stick with the tiles. If you reuse the tiles
for different maps and the try to merge those into one final
map, there will be conflicts. Please try, to split separate
tiles with separate mapids for each of the maps to be merged.<br>
<br>
</li>
<li>Also from the first mail: " They all use different typ-files
matching the file family/product-id of the compiled map."<br>
<ul>
<li>From my understanding, there is no such thing, like a
type-file having FID or PID, other than by filename. I know
that TYPViewer has FID info in its header section, but afaik
that is informal (comment) only. At least, when using UTF8
typefiles (I'm on Linux). <br>
TYPViewer exports/imports/converts UTF8 <-> .typ. If
an UTF8 typefile (having whatever FID in the header) is
provided to mkgmap on the commandline, mkgmap too compiles
to .typ (on-the-fly, during map generation, saved to the
working directory) and uses it for that generated map
correctly. Works standalone too, iirc.<br>
</li>
<li>On the other hand, one .img can only use one typefile
(although it can contain multiple, see below, 2.nd test).
Hence all elements for the final map, must be declared in
the typefile <u>used</u> by the map. On merging maps (like
we target here), only one of the individual maps typefiles
gets used for the result; from the sample below, this could
be the alphabetically first typefile (Gerd?). Its selection
is not dependant on the order of calling the input files.<br>
So you can use the same typefile (w/o any
modifications/adaptions) for different maps (I do that all
the time) but you should take care, that the one used in the
merged map has definitions for all elements of all maps
merged. Maybe you'd want to use that one for the individual
maps then anyway (last sample below).<br>
</li>
</ul>
</li>
</ol>
<p>#1<br>
Lets merge an .img file of Mallorca from 2 separate (simple) .imgs
(built using the same, only renamed typefile):</p>
<blockquote>
<p><font face="monospace">felix@TCHd:~/Downloads/mergetest$ ls -al<br>
insgesamt 92<br>
drwxr-xr-x 2 felix felix 4096 Nov 26 16:41 .<br>
drwxr-xr-x 13 felix felix 4096 Nov 26 16:41 ..<br>
-rw-r--r-- 1 felix felix 61440 Feb 27 2022
Malle-Acuts-6410.img<br>
-rw-r--r-- 1 felix felix 20480 Feb 27 2022
Malle-Bcuts-6420.img<br>
-rw-r--r-- 1 felix felix 710 Feb 24 2020 options.arg</font></p>
</blockquote>
<blockquote>
<p><font face="monospace"><br>
</font></p>
<p><font face="monospace">felix@TCHd:~/Downloads/mergetest$ gmt -i
Malle-Acuts-6410.img <br>
gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP <a class="moz-txt-link-abbreviated" href="http://www.gmaptool.eu">www.gmaptool.eu</a><br>
<br>
File: Malle-Acuts-6410.img, length 61440<br>
Header: 27.02.2022 19:14:05, DSKIMG, XOR 00, V 18.15, Ms
0<br>
Mapset: TKM_Malle-Acuts-6410<br>
<br>
Map length s-f CP prio PID FID name<br>
MAKEGMAP MPS 95 1<br>
64106410 MPC 53363 3 1252 60 T 1 6410
TKM_Malle-Acuts-6410<br>
06410FM1 TYP 888 1 1252 1 6410<br>
00006410 SRT 912 1<br>
<br>
Data MPS<br>
F: PID 1, FID 6410, TrackMap<br>
V: OSM map set (0)</font></p>
<p><font face="monospace"><br>
</font></p>
<p><font face="monospace">felix@TCHd:~/Downloads/mergetest$ gmt -i
Malle-Bcuts-6420.img <br>
gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP <a class="moz-txt-link-abbreviated" href="http://www.gmaptool.eu">www.gmaptool.eu</a><br>
<br>
File: Malle-Bcuts-6420.img, length 20480<br>
Header: 27.02.2022 19:14:05, DSKIMG, XOR 00, V 18.15, Ms
0<br>
Mapset: TKM_Malle-Bcuts-6420<br>
<br>
Map length s-f CP prio PID FID name<br>
MAKEGMAP MPS 95 1<br>
64206420 MPC 12475 3 1252 60 T 1 6420
TKM_Malle-Bcuts-6420<br>
06420FM1 TYP 888 1 1252 1 6420<br>
00006420 SRT 912 1<br>
<br>
Data MPS<br>
F: PID 1, FID 6420, TrackMap<br>
V: OSM map set (0)<br>
<br>
</font></p>
<p><font face="monospace">felix@TCHd:~/Downloads/mergetest$ cat
options.arg <br>
overview-mapname=Malle-6400<br>
overview-mapnumber=64000000<br>
description=TKM-Malle-6400<br>
series-name=TrackMap<br>
family-name=TrackMap<br>
family-id=6400<br>
mapname=64006400<br>
product-id=1<br>
product-version=0815<br>
draw-priority=58<br>
transparent<br>
gmapsupp<br>
input-file=./Malle-Acuts-6410.img<br>
input-file=./Malle-Bcuts-6420.img<br>
output-dir=./<br>
verbose</font></p>
<p><font face="monospace"><br>
</font></p>
<p><font face="monospace">felix@TCHd:~/Downloads/mergetest$ mkgmap
-c options.arg</font></p>
<p><font face="monospace"><br>
</font></p>
<p><font face="monospace">felix@TCHd:~/Downloads/mergetest$ ls -al<br>
insgesamt 184<br>
drwxr-xr-x 2 felix felix 4096 Nov 26 17:31 .<br>
drwxr-xr-x 13 felix felix 4096 Nov 26 16:41 ..<br>
-rw-r--r-- 1 felix felix 79360 Nov 26 17:31 gmapsupp.img<br>
-rw-r--r-- 1 felix felix 5120 Nov 26 17:31 Malle-6400.img<br>
-rw-r--r-- 1 felix felix 157 Nov 26 17:31 Malle-6400.tdb<br>
-rw-r--r-- 1 felix felix 61440 Feb 27 2022
Malle-Acuts-6410.img<br>
-rw-r--r-- 1 felix felix 20480 Feb 27 2022
Malle-Bcuts-6420.img<br>
-rw-r--r-- 1 felix felix 319 Nov 26 17:30 options.arg<br>
</font></p>
<p><font face="monospace"><br>
</font></p>
<font face="monospace">felix@TCHd:~/Downloads/mergetest$ gmt -i
gmapsupp.img <br>
gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP <a class="moz-txt-link-abbreviated" href="http://www.gmaptool.eu">www.gmaptool.eu</a><br>
<br>
File: gmapsupp.img, length 79360<br>
Header: 26.11.2022 17:31:21, DSKIMG, XOR 00, V 8.15, Ms 0<br>
Mapset: TKM-Malle-6400<br>
<br>
Map length s-f CP prio PID FID name<br>
MAKEGMAP MPS 174 1<br>
64106410 MPC 53363 3 1252 60 T 1 6410
TKM_Malle-Acuts-6410<br>
06410FM1 TYP 888 1 1252 1 6410<br>
00006410 SRT 912 1<br>
64206420 MPC 12475 3 1252 60 T 1 6420
TKM_Malle-Bcuts-6420<br>
06420FM1 TYP 888 1 1252 1 6420<br>
00006420 SRT 912 1<br>
<br>
Data MPS<br>
F: PID 1, FID 6410, TrackMap<br>
F: PID 1, FID 6420, TrackMap<br>
V: OSM map set (0)</font><br>
</blockquote>
<p>Discard ...6400.tdb and ...6400.img and rename gmapsupp.img, if
you so like. Loads fine, identical to stacking the individual
maps. <br>
These are very simple map overlays I built from scratch from .gpx
tracks only; very few ways and 1 tile per map only.</p>
<p><br>
</p>
<p>#2<br>
But the process functions as well, if I use a small bbox full
"basemap" (FID 5403) and my much wider bbox transparent
cyclenetwork overlay (FID 7121), both built from OSM data as
outlined above. Here the merged map has way more tiles, shows many
elements only for the small bbox and only the CN ways outside, but
it is only based on my "BICYCLIN TYP" (used for 7121) and the
(mkgmap?) inbuild standard typ for the rest, but not the "EDGE_NL-
TYP" (used for 5403). See my initial remarks regarding typefiles.
<br>
It's not that easy to fix that sample on the fly (since both
typefiles declare identical element types differently), but I
think, separating that and using one typefile for both maps
declaring all elements unique would do the trick.</p>
<p><font face="monospace"> felix@TCHd:~/Downloads/mergetest2$ gmt
-i gmapsupp.img <br>
gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP <a class="moz-txt-link-abbreviated" href="http://www.gmaptool.eu">www.gmaptool.eu</a><br>
</font></p>
<p><font face="monospace"> File: gmapsupp.img, length
68075520<br>
Header: 26.11.2022 17:57:05, DSKIMG, XOR 00, V 8.15,
Ms 0<br>
Mapset: Harri-4567<br>
<br>
Map length s-f CP prio PID FID name<br>
MAKEGMAP MPS 19366 1<br>
54030001 MPC 2754928 3 1252 31 1 5403
DE-Coesfeld<br>
54030002 MPC 3449556 3 1252 31 1 5403
DE-Duelmen<br>
54030003 MPC 2673582 3 1252 31 1 5403
DE-Bocholt<br>
...<br>
EDGE_NL- TYP 28399 1 1252 1 5403<br>
00005403 SRT 912 1<br>
71210001 MPC 128048 3 1252 40 T 1 7121
DE-Cuxhaven<br>
71210002 MPC 107451 3 1252 40 T 1 7121 DE-Husum<br>
71210003 MPC 109457 3 1252 40 T 1 7121 DE-Husum<br>
71210004 MPC 146058 3 1252 40 T 1 7121
DE-Elmshorn<br>
...<br>
71210040 MPC 76301 3 1252 40 T 1 7121 NL-Den
Helder<br>
71210041 MPC 77985 3 1252 40 T 1 7121
NL-Harlingen<br>
...</font><font face="monospace"><br>
71210161 MPC 133738 3 1252 40 T 1 7121
BE-Verviers<br>
...<br>
BICYCLIN TYP 842 1 1252 1 7121<br>
00007121 SRT 912 1<br>
<br>
Data MPS<br>
F: PID 1, FID 7121, osm_dep-nwh-bcsurf-wide_7121<br>
F: PID 1, FID 5403, osm_deh-tc_5403<br>
V: OSM map set (0)</font><br>
</p>
<p>I'm somewhat pressed on time atm to fully check that last
assumption, but I will put that on my bucket-list too, at least to
evaluate, if this tecnique (merging layers of different draw
priority into one final map) finally allows, to control the
draw-priority of elements (e.g. ways), at least to some degree.
That is, to make sure your oneway arrows get plottet on top of the
relevant roads...</p>
<p><br>
</p>
<p>#3<br>
I did one final test though; merging 2 maps created using the same
typefile, but with different, non-overlapping bboxes. No problem!<br>
Please note, the FID 5406 maps typefile (<font face="monospace">EDGE_NL-
TYP</font>) is not even listed by gmt, hence not even included
by mkgmap. That would (will?) be my way to tackle this task.<br>
</p>
<p><font face="monospace">felix@TCHd:~/Downloads/mergetest3$ gmt -i
gmapsupp.img <br>
gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP <a class="moz-txt-link-abbreviated" href="http://www.gmaptool.eu">www.gmaptool.eu</a><br>
<br>
File: gmapsupp.img, length 147324928<br>
Header: 26.11.2022 18:45:09, DSKIMG, XOR 00, V 8.15,
Ms 0<br>
Mapset: Harri-4567<br>
<br>
Map length s-f CP prio PID FID name<br>
MAKEGMAP MPS 2868 1<br>
54030001 MPC 2754928 3 1252 31 1 5403
DE-Coesfeld<br>
...<br>
EDGE_NL- TYP 28399 1 1252 1 5403<br>
00005403 SRT 912 1<br>
54060001 MPC 4410896 3 1252 31 1 5406
DE-Bremervoerde<br>
...<br>
54060030 MPC 2392746 3 1252 31 1 5406
PL-Szczecin<br>
00005406 SRT 912 1<br>
<br>
Data MPS<br>
F: PID 1, FID 5406, osm_deo_5406<br>
F: PID 1, FID 5403, osm_deh-tc_5403<br>
V: OSM map set (0)</font><br>
<br>
</p>
<p>Please keep me posted, if you give it another try.</p>
<p>Cheers Felix<br>
</p>
<br>
</body>
</html>