Thread: Why is 'Suppmap1' in Nuvi 1xxx Inventory? & Why are some maps unselectable named as 'gmapoem'?

Maybe the nüvi 1300 uses some default legacy garbage in the firmware that is just empty placeholders from the past?
Looks that way if you have tried gmapsup2.img and also internal vs. memory card storage.

Some of the terms from a GarminDevice.xml file:

• PreProgrammedMaps
  
  1. gmapprom.img
  2. gmapprom1.img
• SupplementalMaps
  
  1. gmapsupp.img
  2. gmapsup2.img
• BaseMaps
  
  • gmapbmap.img
• TimeZoneMaps
  
  • gmaptz.img
• PreProgrammed3DMaps
  
  1. gmap3d.img
  2. gmap3d1.img
• Supplemental3DMaps
  
  • [GPS or memory card]:\Map\any_name.img
• PreProgrammedDEMMaps
  
  • gmapdem.img
• SupplementalDEMMaps
  
  • gmapdem1.img

OEM data in gmapoem.img is usually some very small files with branded data for dealer POIs.
Some examples of gmapoem.img files from Garmin or branded Garmin units:
[Only registered and activated users can see links. ]
[Only registered and activated users can see links. ]
[Only registered and activated users can see links. ]
[Only registered and activated users can see links. ]

There's similar gmapoem.img files for branded versions of units sold by Tesco, Dixons, Carrefour, Géant, Hyundai etc.

More about the map files here:
[Only registered and activated users can see links. ]



This post suggests that Suppmap1 is the internal gmapsupp.img and that Suppmap is the gmapsupp.img stored on a memory card. That's for nüvi 7x0 & 7x5.

Originally Posted by catymag

Multi maps on Nuvi 7x0/7x5

original poster hulio (thanks)



Nuvi internal (diagnostic utility) OS map naming
-----------------------------------------------------------
7x0/7x5

1. PROM1 = gmapprom.img
2. PROM2 = gmapprom1.img
3. Suppmap1 = gmapsupp.img (nuvi drive only)
4. Suppmap = gmapsupp.img (SD Card drive only)
5. Dir DB = gmapoem.img
6. Basemap = gmapbmap.img

7x5 only

7. TZMap = gmaptz.img
8. 3DMap 1 = gmap3d.img
+9. 3DMap 2 = gmap3d1.img

About the 4 GiB barrier!

Well, you can put as many <= 4 GiB map files as you want in the Map directory of your memory card. As long as there's room for all the files anyway.
The problem is other constraints like how many map tiles your unit supports and the most severe constraint about the number of map families it can support.
If I store all TOPO Norway Adventure in one gmapsupp.img then I have 20 map families there. That's NOT readable by any Garmin unit I've tested including the Garmin Montana 650t. Normally it works with 16 or 17 MapIDs as the total for all maps but not with 20.

@neil
I have garmap2011.3 in unit map folder gmapsupp.img and it shows up in invenyory as.
Suppmap1 ?????-?? 0.00 Garmap2011.3East 0.00 09fa526e.

@ Neli

So many question so little answers. "I know one thing, that I know nothing".

@Ballebar
Thanks for your answer. As usually informative, thoughtful and nicely crafted answer. I resisted responding to it last night (it's almost 8am here now) as i felt it deserved a much more considered answer than my somewhat flippant one above. A lot of that info i was aware of, ie the file naming protocol and paths for some other nuvis like 7x0/7x5, which makes sense for the legacy units with such original naming constraints and is therefore quite understandable. But suppmap1 for gmapsupp.img in the Nuvi's Map folder makes absolutely no sense and apparently cannot be explained away as "some over-looked hangover from some long-ago software predecessor of the 1xxx line?" (my musing) or "Maybe the nüvi 1300 uses some default legacy garbage in the firmware that is just empty placeholders from the past?" (your similar conjecture). So what was Garmin up to? Was it just neccessary for them to leave suppmap1 there because they constructed the 1xxx firmware from some other existing fw as a base? Therefore it was easier/better to have it linked to 'something' than dead? I suppose that makes sense, kind of. But why to to gmapsupp.img in the internal Map folder, when at least to gmapsupp.img in .system or even to gmapsup2.img in sd/Garmin may serve some purpose. I suppose it was just easier because of some fw constraints not understandable by a layman like me. But i'm sure you could figure it out if you could be bothered, however it's simply not worth the effort so please don't try on my account.

I was also only vaguely aware of the use of Dlr DB/gmapoem.img for oem branded images and that as such it cannot be deselected. I'm also of the (perhaps incorrect) impression that Garmin sometimes uses gmapoem.img for preloaded 'normal' maps, and that they also are not deselectable and don't show in Maps/Info, is that so? However, that's not what i was on about with my original question, which was on using 'foreign' maps not normally intended for oem use. It has been answered by ddabcd277 probably as to do with the NT/nonNT type and/or some info in the header which makes sense to me. That explanation of header info would also explain way some are not even recognised as gmapoem.img at all as i had heard.

My >4GB file size comment was a bit of a 'throwaway line' really. I was also vaguely aware of the map tile number/map family number limit constraints. I'm quite aware of the [Only registered and activated users can see links. ], but honestly thought it was 4 gigabytes (GB) less 1 byte. I notice you used 4 GiB (gibibyte). A typo? No, you don't do typos.. so it really is a 4 gibibytes less 1 byte limit?

2^10 vs. 10^3
Historically most people defines 1 kilobyte as 2^10=1024 bytes, 1 megabyte as 1024 kilobytes, 1 gigabyte as 1024 megabytes and so on. That's the definition that was used in the beginning of calculating bits and bytes in computers and PCs.
Storage manufacturers have hijacked the term and by political and technical lobbying got the SI definition of decimal counting for kb, MB, GB, TB etc. to be commercially accepted. They claim that k stands for 10^3=1000, M for 10^6=1000000, G for 10^9=1000000000 and that it allows them to use the decimal definition of prefixes for bytes. That even despite the de facto standard for computer science had been binary 1024 calculated prefixes for decades.

When we where using kB and MB it didn't matter so much if it was decimal or binary definition behind the symbols. But we loose approx. 2.34% for each step in the k -> M -> G -> T -> P ...
1 kB is ~97.66% of 1 KiB
1 MB is ~95.37% of 1 MiB
1 GB is ~93.13% of 1 GiB
1 TB is ~90.95% of 1 TiB
1 PB is ~88.82% of 1 PiB
...
...
So with TB and PB we have lost close to 10% or more from what many of us actually expected from binary calculated units.

Gigabytes vs. gibibytes class action suit nears end

Code:

Please Login or Register to see the links

Microsoft still uses the term gigabyte (GB) as calculating 1024 MB or 1024*1024 kB or 1024*1024*1024 bytes. I'm also using 1 GB as 1024 MB in normal everyday life but tries to be as accurate as possible here in the Noeman forum. So here at Noeman I'm trying to use KiB, MiB, GiB when appropriate. Most file host forums also shows MB but uses binary calculation such as it should be displayed as MiB instead.

We could even complicate it further by using the original definition of a byte - one data word used for CPU calculation or data storage. That means 1 byte = 4 bits in a 4-bit CPU world, 1 byte = 8 bits in a 8-bit CPU environment and so on. In my Windows 7 64-bit OS that would mean 1 byte = 64 bits.

Code:

Please Login or Register to see the links

2^32
If you have a FAT32 file system it means the address space is 32-bits. Calculating from address 0 (zero) and up to 2^32-1. The -1 comes from that you start with address 0. That's the maximum unsigned 32-bit integer that could be used in linear addressing. This is equal to 4 GiB - 1.

Code:

Please Login or Register to see the links

Some (un)usefull historical data
In the old DOS days with 16-bit application there was a lot of tools like DOS Phar Lap Extender to break the OS limit of 16-bit addressing. By using such extenders they could write 32-bit applications to run in a 16-bit OS.

Code:

Please Login or Register to see the links

About the total numbers of map families (MapIDs) that can be used at the same time in a Garmin unit.
I haven't tried to measure this by science and taking the time to test my Garmin units. If I load my 32 GB Samsung Class 10 microSDHC card with 4 City Navigator NT, 7 TOPO maps and 6 BC g2 the result is that some maps is not seen by the unit.
Perhaps Mapperoni would be kind and share his more exhaustive evaluations of that subject. I think Mapperoni tested the capacity of a GPSmap 62 unit with TOPO Norway Adventure. There's a total of 20 maps in that series and all have a different MapID.

I thought the limits put on the map size ( Especially for units like the Montana 650 ) was based on how many "Tiles" were in am image and not the actual size of the image file.

I can't recall exactly what the tile limit was, but it was somewhere around 2025 tiles I thought for official Garmin maps.

For "custom" maps, the tile limit on the Montana used to be 100, but has recently been increased to a 500 tile limit for "Custom" maps on the Montana.

It will also depend on whihc GPS unit you are using and which Firmware/Software version.

If That Topo Norway Advenbture has more than the allowed number of tiles than the GPS will not work.

If there are 20 Map "Families", there well may be over the allowed number of tiles... I don't know.

There may be a way to movfe some of the tiles into another map image file and turn both the img files on using the Montana and they "may" both show up as one "may" overlay the other.

BTW.... I'm not an expert. Like many here... I'm still learning.