GPSMapEdit/cGPSmapper - Splitting and Performance

[adalbert1977]

Splitting the map (the MP files) with GPSMapEdit (Tools->Split map to files) (and due to this: compiling multiple, smaller IMG-s) does improve the rendering speed of the final (combined) IMG file uploaded to the Garmin GPS unit? Or only a smaller "TRE Size" does improve the rendering speed despite of a single big raw IMG? I've noticed that the bigger maps ar distributed with multiple IMG-s (or multiple GMP compartments), and is not clear to me, if this is only in favor of easier re-edit and re-compiling of the maps, or improves the rendering speed as well.

[Boyd]

I don't know how much you can generalize since the detail level on different maps can be wildly different. But I have done some experimentation myself. I make maps with an extreme amount of detail, and have found that smaller tiles (.img files) perform much better on the GPS. In my case, I try to keep the individual tiles between 1MB and 2MB each. If I use 24k USGS quad boundaries for tiles, it meets this goal for my own maps.

But, as I said, I make maps that have a very high data density, such as this.  http://www.gpsfiledepot.com/maps/view/276/

I think the GPS must load all tiles necessary to display your current location on the screen. So you have a trade-off: with large tiles it may only need to access a single tile but it will take longer to load it. With small tiles it will need to load more of them, but they can be accessed more quickly. So let's say you have a map that consists of four 4 MB tiles. If you are right in the middle of that map, the GPS will have to load all 4 tiles, or 16MB of data to cover the screen. But if you make the same map with 16 tiles of 1MB each, the GPS will probably only need to load 4 of those little tiles, or 4MB of data.

Really, it's best to do some experiments on your own and see how it works. Unless you are making a very small map, I don't think that a single .img file will perform very well on the GPS.

[popej]

Using small value for TRE size speeds up map display. I think this value defines internal division of a tile into parts, that can be processed independently. I haven't tested speed against tile size. I divide maps, when they are to big to compile as a single file.

[Seldom]

On my maps I "slice" all objects except routable ones.  This makes things like contours much more manageable (shorter).  My tiles are 1 degree square, and I use 40 foot contours, which in the Grand Canyon is a minimum of 100 contours top to bottom.

[Boyd]

I think this value defines internal division of a tile into parts, that can be processed independently.

Thanks, that is interesting. Never looked into the details before. But it explains why I can see smaller tiles being individually rendered on the GPS screen.

[93ToyTruck]

I've got a large map with a lot of topo detail. The only way I could get it to compile was to set TRE to 500 and RGN to 250 then split the map to files. The benefit I saw in splitting the map was a big decrease in compile time. Cgpsmapper keeps using more memory the longer it runs and starts slowing down. Splitting the files releases memory every time it finishes a file and starts the next.

I didn't notice an improvement in GPS render time after splitting the files. Perhaps not a small enough split? I just kept decreasing the split size until it didn't improve compile time. If you split it there doesn't seem to be a need to slice. Correct?

[popej]

The lower TRE size the bigger img size and map have to be divided into smaller tiles. You will have less problems with tile size reaching compiler limits when using big TRE. And there is no good tool for splitting routable maps, sometimes easier to increase TRE.

According to cgpsmapper manual RGN limit has no influence on map speed, but I haven't tested it.