Montana Internal Storage cleanup

Discussion in 'Mapping & Navigation' started by wbbnm, Sep 29, 2013.

  1. wbbnm

    wbbnm Long timer

    Joined:
    Dec 18, 2007
    Oddometer:
    3,093
    Location:
    Minnesota
    I was just looking at the contents of the GPX files in the internal storage area of my Montana.

    A lot of them have built up over the past 14 months. Some only have a couple of waypoints in them. I was wondering if anyone has ever gone to the trouble of combining tracks and waypoints into fewer files?

    It could be done with Mapsource and I guess Basecamp. But it would be a chore and is it worth the trouble to maybe get some better performance at startup?

    Another question. I noticed on my last ride that the current track was only overlaying my planned track for maybe a mile or so. I don't remember this happening before. I did a brief look for some setting I might have changed, but couldn't find any.

    It was interesting that in one part of a ride we looped back to a place we had been earlier in the day. The Current track was visible in this area.

    Any insights?
    #1
  2. Countdown

    Countdown Long timer

    Joined:
    Oct 20, 2003
    Oddometer:
    6,731
    Location:
    Carson City/Ridgecrest
    I have had some strange Active Log displays even on old 76 but as I remember they were a function of the Active Log segments (Active Log 001) or changing the color mid day. Pannicked but when I got to computer it was all there.
    #2
  3. wbbnm

    wbbnm Long timer

    Joined:
    Dec 18, 2007
    Oddometer:
    3,093
    Location:
    Minnesota
    Yes I was a bit panicked too, but I checked and the complete track was in what the Montana calls the current track. And the data did get transferred to the archived track.

    I need to do some more research to see if I can find any setting that might be causing this. At times I like it and at times I don't.
    #3
  4. DRTBYK

    DRTBYK All Things GPS

    Joined:
    Mar 26, 2003
    Oddometer:
    7,128
    Location:
    47°50′15.8″N, 119°56′21.9″W
    It's just a display optimization function. A few software releases back Garmin changed the Current Track code to use less memory. As you noticed, the Current Track is complete and intact.
    #4
  5. wbbnm

    wbbnm Long timer

    Joined:
    Dec 18, 2007
    Oddometer:
    3,093
    Location:
    Minnesota

    Thanks Dan. I will stop worrying about it.

    I am not sure what firmware I am running. I studiously avoided updates about a year ago due to all the problems people were having. But I think I might have accidentally updated it sometime in the last few months.
    #5
  6. DRTBYK

    DRTBYK All Things GPS

    Joined:
    Mar 26, 2003
    Oddometer:
    7,128
    Location:
    47°50′15.8″N, 119°56′21.9″W
    You ought to update to the latest version (5.40). It has fixed many issues.
    #6
  7. wbbnm

    wbbnm Long timer

    Joined:
    Dec 18, 2007
    Oddometer:
    3,093
    Location:
    Minnesota

    Okay. But how long has it been out? I would not want to update unless the community forerunners have had at least a couple of months to use it and find any fatal bugs.
    #7
  8. SteveAZ

    SteveAZ Long timer

    Joined:
    Sep 23, 2002
    Oddometer:
    1,283
    Location:
    AZ
    I periodically take the waypoints I want to keep long term in the unit and pile them into one waypoint file. It doesn't take long at all. I have no idea if it does anything positive or negative to performance at startup or any other time, it's just to keep my data more organized.

    I do keep some .gpx files that contain sets of waypoints, etc for a given area I may go infrequently. I usually keep these in the gpx folder on the SD card. Again, more just as a way to keep my data organized...
    #8
  9. DRTBYK

    DRTBYK All Things GPS

    Joined:
    Mar 26, 2003
    Oddometer:
    7,128
    Location:
    47°50′15.8″N, 119°56′21.9″W
    When the Montana boots up it makes a note of what and where all of the data is on the unit; it's called indexing.

    When you put all of your data into a single file the Montana must put all of the data in that file into active memory and keep it there whenever you preform a task with any object in the file. So, if you want to navigate to a waypoint and that waypoint is in a GPX file with 200 other waypoints, ALL 200 waypoints get read into active memory even though only one waypoint is being used.

    On the other hand, if you have your data parsed into separate GPX files (the way the unit expects to see it) then the Montana only has to read into active memory the data it needs to do whatever task you asked it to do.

    So, collecting your data into singular GPX file(s) is not a way to "optimize" anything other than your view of the data when you have the unit connected to your computer and you're not using BaseCamp.
    #9
  10. SteveAZ

    SteveAZ Long timer

    Joined:
    Sep 23, 2002
    Oddometer:
    1,283
    Location:
    AZ
    Not arguing. Please cite your source for this.
    #10
  11. DRTBYK

    DRTBYK All Things GPS

    Joined:
    Mar 26, 2003
    Oddometer:
    7,128
    Location:
    47°50′15.8″N, 119°56′21.9″W
    It's OK. I asked the same questions when this was added to the Montana Code back around v2.9-3.0(?). The explanation was given to me by a Montana Developer.
    #11
  12. SteveAZ

    SteveAZ Long timer

    Joined:
    Sep 23, 2002
    Oddometer:
    1,283
    Location:
    AZ
    I see. Then it sounds as though as soon as we do a "find" for a waypoint, whether the waypoints are all in one .gpx or no, since "the Montana must put all of the data in that file into active memory and keep it there whenever you preform a task with any object in the file" it would have to move the waypoint data from all the .gpx files into "active memory" to search all the waypoints whether a search by name or by proximity?
    #12
  13. DRTBYK

    DRTBYK All Things GPS

    Joined:
    Mar 26, 2003
    Oddometer:
    7,128
    Location:
    47°50′15.8″N, 119°56′21.9″W
    The Index is created once at boot and it is the Index that is being "searched" not all of the files. When you look at waypoint data the file is opened. When your choice or search results are used in a Routing operation, only then does it get moved into memory so if the unit has to move 2000 waypoints worth of data into memory when only three waypoints are being used, that takes up a lot of space and will slow things down.

    That's how it was explained to me anyway. I asked because I had a file with 7800+ Campground waypoints in it. They suggested I use the POILoader to compress them to POI's - apparently POI's are parsed on the fly and data extracted when needed.
    #13
  14. wbbnm

    wbbnm Long timer

    Joined:
    Dec 18, 2007
    Oddometer:
    3,093
    Location:
    Minnesota
    As a software engineer I find the idea of putting all the data in memory very attractive. This generally makes code run much faster than continually opening and reading disc files.

    But all my experience is with mechanical discs. I don't have much of a feeling for delay times associated with solid state memories.

    I guess 8000 waypoints could cause a bit of a slowdown accessing memory, but I wouldn't think it would be more than a few milliseconds.
    #14
  15. DRTBYK

    DRTBYK All Things GPS

    Joined:
    Mar 26, 2003
    Oddometer:
    7,128
    Location:
    47°50′15.8″N, 119°56′21.9″W
    It's about total memory management not just the read/write of the active data object. There is finite memory and if it gets loaded up with unnecessary data, then there has to be a lot of swapping which is slow relatively speaking.
    #15
  16. SteveAZ

    SteveAZ Long timer

    Joined:
    Sep 23, 2002
    Oddometer:
    1,283
    Location:
    AZ
    Memories are so ridiculously dense and inexpensive these days.

    .gpx is a very space inefficient way of storing waypoint data and
    A waypoint.gpx file with over 600 waypoints is only 336KB (*kilo*bytes, not megabytes).

    I would suggest there are order of magnitudes more memory than the 336KB and that the memory being finite has no relevance to loading a waypoint file this size - there would be no reason for "swapping".

    Moving a file that size from Flash to RAM would probably take well under 1ms, even on a very slow and busy memory bus. Heck you could turn it into a binary file while moving it and make it *much* smaller and improve access time if any of this were an issue.

    It's very hard for me to understand how a 600 waypoint file would give the unit any grief whatsoever. Even a 7000 waypoint shouldn't although it wouldn't surprise me at all if the s/w architects never envisioned that someone would use that large a waypoint file. Sort of a "640 K[B of RAM] ought to be enough for anyone"...
    #16
  17. DRTBYK

    DRTBYK All Things GPS

    Joined:
    Mar 26, 2003
    Oddometer:
    7,128
    Location:
    47°50′15.8″N, 119°56′21.9″W
    :dunno

    I'm with ya...and I doubt that they actually use GPX formatted data internally. I'm sure it is in binary format. I'm just being a parrot on the topic since I don't really have any way of knowing exactly what Garmin's internal code architecture looks like. There underlying OS is Android/Apache based so we can speculate -- which is always fun.:D

    My experience with the last couple of dev teams I've had contact with leads me to believe that they have very tight cost-to-produce targets as do most low-volume consumer electronics companies these days.

    Fortunately [for me] I don't design them or code them, I just test, evaluate and use them. :deal
    #17