GPSrChive Discussion Forum

On the german forum, we noticed a strange problem regarding address search with OSM maps on Montana 7x0. This seems only to happen on Montana 7x0, as other devices, like GPSMap 276Cx or Oregon 6xx, do not show that issue. Based on my further tests, this can happen on all OSM maps including TopoActive.

The problem seems to be, if multiple OSM maps are installed and both habe for the same country an address database, addresses in search can be only found from that map, which was first indexed by Montana 7x0. On GPSMap 276Cx and Oregon, addresses from both maps ca be successfully shown.

Let' assume, we use two maps here, Freizeitkarte_FRA (France) and Freizeitkarte_ITA (Italy).
You can get them here: http://www.freizeitkarte-osm.de/garmin/en/index.html
The following test is assuming, that TopoActive and City Navigator maps have been uninstalled with Garmin Express.

Random public address from Google Maps for Frace:
*) 5 Rue Albert Camus, 75010 Paris (10e Arrondissement), Frace

Random public address from Google Maps for Italia:
*) 11 Via Diacceto, 53100 Siena, Itally

------------------------------------------

Test A)
1) Install Freizeitkarte_ITA.img
2) Reboot Montana to index map as first
3) Install Freizeitkarte_FRA.img
4) Reboot Montana to index map as second
5) Open Where To?
6) Open Addresses
7) Open Search Area
8) Open Enter State/Province
9) Enter Italia
10) Open Search Area
11) Open Enter City
12) Enter Siena
13) Choose Siena
14) Open Street Name
15) Enter Diacceto
16) Open Number
17) Enter 11

Up to here, it works correctly. The address is being found in Italia.

18) Go to main menu
19) Open Where To?
20) Open Addresses
21) Open Search Area
22) Open Enter State/Province
23) Enter France
24) Open Search Area
25) Open Enter City
26) Enter Paris

What happens: On Montana 7x0, no Paris is being found. On GPSMap 276Cx and Oregon 6xx it's being found.
If you now delete Freizeitkarte_ITA.img, you will be able to find the address in Paris.

------------------------------------------

Test B)
1) Install Freizeitkarte_FRA.img
2) Reboot Montana to index map as first
3) Install Freizeitkarte_ITA.img
4) Reboot Montana to index map as second
5) Open Where To?
6) Open Addresses
7) Open Search Area
8) Open Enter State/Province
9) Enter France
10) Open Search Area
11) Open Enter City
12) Enter Paris
13) Choose 10e Arrondissement
14) Open Street Name
15) Enter Albert Camus
16) Open Number
17) Enter 5

Up to here, it works correctly. The address is being found in France.

18) Go to main menu
19) Open Where To?
20) Open Addresses
21) Open Search Area
22) Open Enter State/Province
23) Enter Italy
24) Open Search Area
25) Open Enter City
26) Enter Siena

What happens: On Montana 7x0, no Siena is being found. On GPSMap 276Cx and Oregon 6xx it's being found.
If you now delete Freizeitkarte_FRA.img, you will be able to find the address in Siena.

------------------------------------------

At first glance, the first OSM card indexed 'wins'. If you take a look at Freizeitkarte_FRA.img and Freizeitkarte_ITA.img, there is something. Both cards come with address entries for 'France' and 'Italia' by default. This is probably normal because smaller parts of the neighboring countries are taken with you when you cut them out in a rectangle from OSM raw data. Since France and Italy border each other, both maps of the other country have a few addresses close to the border.

Apparently the Montana 700 series has a problem if several OSM maps for the same country have addresses with them. Then the map that was indexed first always seems to win. The second card may then be indexed incorrectly, as there is a strange observation I made. When looking through the list of all cities, you can see only a few entries, but there is a big long list with empty entries.

Hi.
Though i haven't tried as thoroughly as ConiKost, i am close to completely certain the same occurs on 66st (with most firmwares and also with 9.60).
I use multiple maps, locations are for sure on some maps, but depending on which was added first the location on the maps added later may not be possible to find. Again i think a lot of the firmware is shared between these units and i sure hope there will be a fix for all of them.

We are waiting on some painfully s...l...o...w map downloads from the provided source before we can independently test this behavior.

Even so, I already have some theories as to what might be happening here, but I can not verify them until after I have the map images to work with.

I suspect, like so many third party map providers, while they use unique file names for each map provided, they do not use unique embedded map identification credentials, essentially making all their maps appear to most Garmin devices as individual sections of the same map set.

The GPSr will 'build' a routing database for each *.img map when it is first indexed, which includes most (if not all) routable data. Should any additional *.img map files be found that share identical embedded identification credentials, the routing data in the additional *.img map(s) can not be integrated into the previously completed routing index, and is will not be available on the device.

If this is the case, there are two possible solutions:

1. Convince the map author to assign a unique embedded map ID for each *.img file they provide
2. Combine all maps sharing the same embedded map ID into a single *.img file

Perhaps some of our readers will be able to perform these tests and report their findings before our S...L...O...W downloads are completed and we find time to test for ourselves...

Update:

Both maps, Italy and France, from the above source, are internally identified as Garmin City Navigator maps.

gpsrchive wrote: Tue Jan 04, 2022 3:46 am We are waiting on some painfully s...l...o...w map downloads from the provided source before we can independently test this behavior.

Sorry to hear. Must be some kind of bad routing to you, as I can download with full speed (~30mb/s).
Do you want that I upload those maps to my server? Maybe it's faster then?

gpsrchive wrote: Tue Jan 04, 2022 3:46 am Even so, I already have some theories as to what might be happening here, but I can not verify them until after I have the map images to work with.

Happy to hear your ideas

gpsrchive wrote: Tue Jan 04, 2022 3:46 am I suspect, like so many third party map providers, while they use unique file names for each map provided, they do not use unique embedded map identification credentials, essentially making all their maps appear to most Garmin devices as individual sections of the same map set.

Are you talking about FID and PID?
F: PID 1, FID 6250, Freizeitkarte_FRA
F: PID 1, FID 6380, Freizeitkarte_ITA

Those should be fine?

gpsrchive wrote: Tue Jan 04, 2022 3:46 am The GPSr will 'build' a routing database for each *.img map when it is first indexed, which includes most (if not all) routable data. Should any additional *.img map files be found that share identical embedded identification credentials, the routing data in the additional *.img map(s) can not be integrated into the previously completed routing index, and is will not be available on the device.

If this is the case, there are two possible solutions:

1. Convince the map author to assign a unique embedded map ID for each *.img file they provide
2. Combine all maps sharing the same embedded map ID into a single *.img file

Since FID is not the same, this should not apply?
And the questio is still open, why other GPSr do not have a problem here?

gpsrchive wrote: Tue Jan 04, 2022 4:44 am Both maps, Italy and France, from the above source, are internally identified as Garmin City Navigator maps.

This seems normal. Every different OSM map I had, was always being identified as CN. I read somewhere, that there is a flag on img files, which says if map is topo or not. But non topo maps cannot be further differentiated, AFAIK.

There are map identification details embedded deeper than FID and PID that Garmin are using for 'automatic routing' features on newer devices. Older devices never had this feature and therefore ignore this information.

None of this information is documented by Garmin, so third party map makes have to rely on reverse engineered data.

When time allows. I will first verify your workflow with the maps you used, then test again after modifying one of the maps to see if the issue is resolved.