Hey Harri,
do not retire an old friend easily.
Re-reading my mail, I may have falsely assumed things as given and been
to brief in places.
Rereading yours carefully, I think, I see potential tripping points now.
Why not give it one last fight?
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 .
As for the potential tripping points:
1. Your first mail reads: "I'm generating multiple files [.imgs], all
with different family-id, product-id, mapname and map description."
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."
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.
2. Also from the first mail: " They all use different typ-files
matching the file family/product-id of the compiled map."
* 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).
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.
* 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
_used_ 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.
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).
#1
Lets merge an .img file of Mallorca from 2 separate (simple) .imgs
(built using the same, only renamed typefile):
felix@TCHd:~/Downloads/mergetest$ ls -al
insgesamt 92
drwxr-xr-x 2 felix felix 4096 Nov 26 16:41 .
drwxr-xr-x 13 felix felix 4096 Nov 26 16:41 ..
-rw-r--r-- 1 felix felix 61440 Feb 27 2022 Malle-Acuts-6410.img
-rw-r--r-- 1 felix felix 20480 Feb 27 2022 Malle-Bcuts-6420.img
-rw-r--r-- 1 felix felix 710 Feb 24 2020 options.arg
felix@TCHd:~/Downloads/mergetest$ gmt -i Malle-Acuts-6410.img
gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP www.gmaptool.eu
File: Malle-Acuts-6410.img, length 61440
Header: 27.02.2022 19:14:05, DSKIMG, XOR 00, V 18.15, Ms 0
Mapset: TKM_Malle-Acuts-6410
Map length s-f CP prio PID FID name
MAKEGMAP MPS 95 1
64106410 MPC 53363 3 1252 60 T 1 6410 TKM_Malle-Acuts-6410
06410FM1 TYP 888 1 1252 1 6410
00006410 SRT 912 1
Data MPS
F: PID 1, FID 6410, TrackMap
V: OSM map set (0)
felix@TCHd:~/Downloads/mergetest$ gmt -i Malle-Bcuts-6420.img
gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP www.gmaptool.eu
File: Malle-Bcuts-6420.img, length 20480
Header: 27.02.2022 19:14:05, DSKIMG, XOR 00, V 18.15, Ms 0
Mapset: TKM_Malle-Bcuts-6420
Map length s-f CP prio PID FID name
MAKEGMAP MPS 95 1
64206420 MPC 12475 3 1252 60 T 1 6420 TKM_Malle-Bcuts-6420
06420FM1 TYP 888 1 1252 1 6420
00006420 SRT 912 1
Data MPS
F: PID 1, FID 6420, TrackMap
V: OSM map set (0)
felix@TCHd:~/Downloads/mergetest$ cat options.arg
overview-mapname=Malle-6400
overview-mapnumber=64000000
description=TKM-Malle-6400
series-name=TrackMap
family-name=TrackMap
family-id=6400
mapname=64006400
product-id=1
product-version=0815
draw-priority=58
transparent
gmapsupp
input-file=./Malle-Acuts-6410.img
input-file=./Malle-Bcuts-6420.img
output-dir=./
verbose
felix@TCHd:~/Downloads/mergetest$ mkgmap -c options.arg
felix@TCHd:~/Downloads/mergetest$ ls -al
insgesamt 184
drwxr-xr-x 2 felix felix 4096 Nov 26 17:31 .
drwxr-xr-x 13 felix felix 4096 Nov 26 16:41 ..
-rw-r--r-- 1 felix felix 79360 Nov 26 17:31 gmapsupp.img
-rw-r--r-- 1 felix felix 5120 Nov 26 17:31 Malle-6400.img
-rw-r--r-- 1 felix felix 157 Nov 26 17:31 Malle-6400.tdb
-rw-r--r-- 1 felix felix 61440 Feb 27 2022 Malle-Acuts-6410.img
-rw-r--r-- 1 felix felix 20480 Feb 27 2022 Malle-Bcuts-6420.img
-rw-r--r-- 1 felix felix 319 Nov 26 17:30 options.arg
felix@TCHd:~/Downloads/mergetest$ gmt -i gmapsupp.img
gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP www.gmaptool.eu
File: gmapsupp.img, length 79360
Header: 26.11.2022 17:31:21, DSKIMG, XOR 00, V 8.15, Ms 0
Mapset: TKM-Malle-6400
Map length s-f CP prio PID FID name
MAKEGMAP MPS 174 1
64106410 MPC 53363 3 1252 60 T 1 6410 TKM_Malle-Acuts-6410
06410FM1 TYP 888 1 1252 1 6410
00006410 SRT 912 1
64206420 MPC 12475 3 1252 60 T 1 6420 TKM_Malle-Bcuts-6420
06420FM1 TYP 888 1 1252 1 6420
00006420 SRT 912 1
Data MPS
F: PID 1, FID 6410, TrackMap
F: PID 1, FID 6420, TrackMap
V: OSM map set (0)
Discard ...6400.tdb and ...6400.img and rename gmapsupp.img, if you so
like. Loads fine, identical to stacking the individual maps.
These are very simple map overlays I built from scratch from .gpx tracks
only; very few ways and 1 tile per map only.
#2
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.
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.
felix@TCHd:~/Downloads/mergetest2$ gmt -i gmapsupp.img
gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP www.gmaptool.eu
File: gmapsupp.img, length 68075520
Header: 26.11.2022 17:57:05, DSKIMG, XOR 00, V 8.15, Ms 0
Mapset: Harri-4567
Map length s-f CP prio PID FID name
MAKEGMAP MPS 19366 1
54030001 MPC 2754928 3 1252 31 1 5403 DE-Coesfeld
54030002 MPC 3449556 3 1252 31 1 5403 DE-Duelmen
54030003 MPC 2673582 3 1252 31 1 5403 DE-Bocholt
...
EDGE_NL- TYP 28399 1 1252 1 5403
00005403 SRT 912 1
71210001 MPC 128048 3 1252 40 T 1 7121 DE-Cuxhaven
71210002 MPC 107451 3 1252 40 T 1 7121 DE-Husum
71210003 MPC 109457 3 1252 40 T 1 7121 DE-Husum
71210004 MPC 146058 3 1252 40 T 1 7121 DE-Elmshorn
...
71210040 MPC 76301 3 1252 40 T 1 7121 NL-Den Helder
71210041 MPC 77985 3 1252 40 T 1 7121 NL-Harlingen
...
71210161 MPC 133738 3 1252 40 T 1 7121 BE-Verviers
...
BICYCLIN TYP 842 1 1252 1 7121
00007121 SRT 912 1
Data MPS
F: PID 1, FID 7121, osm_dep-nwh-bcsurf-wide_7121
F: PID 1, FID 5403, osm_deh-tc_5403
V: OSM map set (0)
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...
#3
I did one final test though; merging 2 maps created using the same
typefile, but with different, non-overlapping bboxes. No problem!
Please note, the FID 5406 maps typefile (EDGE_NL- TYP) is not even
listed by gmt, hence not even included by mkgmap. That would (will?) be
my way to tackle this task.
felix@TCHd:~/Downloads/mergetest3$ gmt -i gmapsupp.img
gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP www.gmaptool.eu
File: gmapsupp.img, length 147324928
Header: 26.11.2022 18:45:09, DSKIMG, XOR 00, V 8.15, Ms 0
Mapset: Harri-4567
Map length s-f CP prio PID FID name
MAKEGMAP MPS 2868 1
54030001 MPC 2754928 3 1252 31 1 5403 DE-Coesfeld
...
EDGE_NL- TYP 28399 1 1252 1 5403
00005403 SRT 912 1
54060001 MPC 4410896 3 1252 31 1 5406 DE-Bremervoerde
...
54060030 MPC 2392746 3 1252 31 1 5406 PL-Szczecin
00005406 SRT 912 1
Data MPS
F: PID 1, FID 5406, osm_deo_5406
F: PID 1, FID 5403, osm_deh-tc_5403
V: OSM map set (0)
Please keep me posted, if you give it another try.
Cheers Felix
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
