Menu

MOBAC, Java and BaseCamp

4 days ago
20 hours ago
  • Robert G Birch

    Robert G Birch - 4 days ago

    A couple of observations that may help:

    1. MOBAC hangs after lots of CPU use and a Java outofmemory exception if the area selected is very close to the area displayed. It does this on “Add selection” from multiple WTMS soures, to multiple atlas types, and in two tested MOBAC versions. I was working with only about 15 WTMS tiles at zoom 15. Everything is fine if the area selected is well inside the area displayed.

    2. MOBAC readme says under the Garmin Custom Map heading that if a map is larger than 1024x1024 pixels it will be automatically scaled down to fit into this size, and this can be prevented by setting the max map size i(n the settings dialog) to 1024. This may (mostly) be true for some Garmin GPSr units (not tested); but it is false for BaseCamp (tested). In fact, MOBAC seems to set Garmin Custom Map max to 1024, no matter what size is in settings. For a large map, this results in a low resolution that is useless in BaseCamp (which can handle very large image files as overlays). With large files, one can zoom in to see fine details in BaseCamp.

    So, for BaseCamp, it is better to use MOBAC Google Earth Overlay, at a high map size setting. This generates a KMZ file that BaseCamp can handle (not a Google superoverlay). I have used zoom 15 at 12800 x 8448 pixels (memory size about 310 MB) without problems.

    These are just work-arounds, but not everyone who is interested may discover them without help.

    Thank you for all your work to provide such a useful tool.

     
    • r_x

      r_x - 3 days ago

      Before Java is running into an outofmemory error is is quite usual that CPU usage increases. This is because the JVM has it's own RAM/memory management and if the JVM is close to an OOM it tries to recover as much memory as possible by performing a full garbage collector(GC) run. The GC on modern JVM versions runs in parallel and thus uses all available CPU cores. Fine tuning the GC by command-line options is a science of it's own and also depends on the actual use JVM and it's version.

      Garmin Custom Map atlas format is designed to always output only maps of size 1024. If you have a Garmin device that doesn't has this restriction, then using Google Earth Overlay atlas format is the correct choice.
      I expect Garmin device owners to select the correct format based on the device.

      If you set the MAximum Map Size in Settings to 1024 this only prevents scaling of the images when using Garmin Custom Map atlas format. The map image size will still be 1024, that is the way it is designed.

       
  • Robert G Birch

    Robert G Birch - 3 days ago

    Thanks r_x. I am a map user (not a computer scientist or program developer), so I will not understand everything. But it may still help you or other users when I report:

    1. I do not know why MOBAC/Java complains when the selection is close to the display size . We users can avoid the problem once we know about it. In case it helps you I have tried to attach a doc file including some of the Java clipboard reports (many other times hung without such a report) and a screen-grab that illustrates what was going on.

    2. I expected a Garmin Custom Map atlas to contain multiple image files of 1024 max size. Instead it always contained a single file of the large area scaled down to 1024 max size. This is useless of course. But a Google Earth Overlay atlas contains a single large (high-res) file if MOBAC map size is set high, or lots of smaller files if MOBAC map size is set smaller. This is what I expected also from the Garmin Custom Map atlas. Garmin BaseCamp imports either the single-image or the multi-image "Google Earth" type KMZ from MOBAC, so users can adapt once they know the trick. (I did not find where you warned of this.)

    3. The documentation is a big help, but still a bit sparse for average users. If you update the readme some time, maybe you would like to add under "Description" (or a new "Using MOBAC" section) something like:

    An "Atlas" is a collection of map tiles in a format suited to another specified program. Atlases are stored in an "atlases" folder under the MOBAC folder. The format is not saved with the atlas, though it may sometimes be deduced from the atlas content.

    A "Profile" is a record of the mapsource (source of tiles), save area, save zoom levels and format to make an atlas. It must be saved at the time of atlas creation. Profiles are saved as "mobac-profile-*.xml" in the MOBAC folder.

    Otherwise there is no function to load an atlas. A "custom tile files source.xml" file can be created to use some saved atlas formats (and some plain file formats), but not Oruxmaps.

    A "Bookmark" is a record of a saved mapsource (source of tiles), display zoom and location for a viewed map. Bookmarks are saved in settinmgs.xml in the MOBAC folder.

    Thank s again for all your work to provide such a useful tool.

     
    • r_x

      r_x - 2 days ago

      MOBAC is an open source project. Feel free to participate and provide detailed documentation. We can e.g. create a page for Garmin devices in the Wiki: https://sourceforge.net/p/mobac/wiki/Home/

      How much RAM does your system have? I have seen in the OutOfMemory error messages that MOBAC is by default limited to 4GB. MOBAC can be started with additional configuration to allow using more RAM - if you have.

       
  • Robert G Birch

    Robert G Birch - 2 days ago

    Hi r_x. Thanks again for the suggestions. To answer your question: my system has 16GB physical ram and a paging file managed by Windows 10. This may be the limitation, but it is strange that it applies at the point of area selection and only when the selection is close to the MOBAC display area (and with so few tiles). Anyhow, it is easy to work around (once one knows the trick) by keeping the selection area well within the display area - then it works fine with my system even if thousands of tiles are selected. No Java memory setting changes required.

    I am not sure what more I can provide to help (beyond what I already sent).

    I do not have any Garmin GPSr that uses "custom maps". Only the long-standing PC program Garmin BaseCamp. It is fine with MOBAC Google Earth Overlay atlases, as mentioned.

    If you are open to other small suggestions to help users of your great tool, maybe in the next version you could consider:

    1. Update the README to include the current atlas formats;
    2. Explain Settings > Map size "Number of tiles to overlap maps regions". (I just leave it alone).
    3. Note that for EPSG:3857 maps with contiguous zoom levels the OruxMaps developer does not recommend either of the MOBAC-listed "OruxMaps" formats. Rather he recommends the (more compact, more compatible and easier to create) MOBAC-listed "MBTiles SQLite" format.
      https://oruxmaps.com/forum/index.php?msg=54567
     
    • r_x

      r_x - 1 day ago

      You can change the maximum RAM/heap size of Java by creating a file Mobile Atlas Creator.ini next to Mobile Atlas Creator.exe.

      In the ini file just put one line of text -Xmx8g and save it. Next time you start MOBAC using exe file MOBAC will have access to up to 8GB of RAM.

      Regarding the update to Readme.md file: You can find the latest version here: https://sourceforge.net/p/mobac/git/ci/main/tree/README.md

      Just download the file, add the information you think that is missing and then send me the modified file.

       
  • Robert G Birch

    Robert G Birch - 20 hours ago

    I am happy to insert the suggestions made above if this helps you to update the README file.
    Is it OK to use notepad++?
    Should the suggested additions be marked somehow?

    I can add the available atlas formats to the README list, but I do not know the technical details comparable to those provided for existing formats in the list. It is quite useful for users to know such things, for example the special features of any format.
    Are you (or someone else) willing to add the technical details?

     

Log in to post a comment.