It is taking an increasing length of time to open the Memory-Map overlay properties tree on my PC. When the app is started without opening the overlay tree it is pretty fast but when the overlays are opened, either at startup or afterwards it is now taking 35 to 40 seconds. Additionally, even when the overlay tree has already been opened, opening a GPX file containing a recorded track (exported from my Android phone in the standard way) takes about 70 to 80 seconds,

Compared to many forum contributors I suspect that I don't have a colossal amount of overlay data; I have deleted unnecessary routes and archived most of my tracks from previous years. That leaves about 140 tracks, 60 routes and about 8,800 waypoints in the tree. So I can't understand what it is that is taking so long.

I should add that this is not a certain other well documented problem which had happened to a few of us in which the maps themselves were taking a very long time to open, when switching from one to another for example. Although the solution for that is a rather drastic complete uninstall and deletion of registry keys etc followed by a reinstallation, it totally fixed the problem for good.

My problem is specific to opening the overlay tree for the first time during each Memory-Map session and to opening GPX files. My PC is well specified and all other M-M functions are behaving as they should.

Apologies if this topic has been covered before but I couldn't find it.

Thanks

Tim

My guess is that the tracks may be the issue. Roughly how many trackpoints are associated with these tracks?

Thanks for your reply.

I currently have 142,895 points in 130 tracks. Does that sound problematic ?

Could you summarise what M-M is actually doing in terms of data processing when it opens the overlay tree? I had always imagined that the data for a given track was dormant until loaded by making the track visible or by inspecting its properties for example but maybe that isn't the case.

Also could you recommend some 'best practice' housekeeping techniques, in view of the answers to the above questions.

Regards

Tim

That is a lot of trackpoints and large numbers of tracks tend to be more problematic than other overlay items. I cannot speak to the exact process used when the tree is opened, but I think you will find the article below helpful in managing overlays.

HOUSEKEEPING

Hi Tim,

It depends how long are the tracks, but over 1,000 points per track does seem rather excessive.

The track properties window has a "Reduce" button which "decimates" the number of trackpoints (I believe it actually halves the number of points in an "intelligent" manner, each time it is used). But save the track(s) to a file first, because I don't think there is an "undo" facility.

Cheers, Alan.

Hi Alan,

Thanks for the advice. I have been wary of using the 'Reduce' button but clearly I should experiment with it, saving my tracks before I try it.

However, following up on the advice from USmmtech I have been archiving and deleting my various track categories, and after deleting ALL my tracks I still found that it was taking nearly 40 seconds to open my overlay tree. When I deleted the routes it really made a considerable difference. So I think it is really the routes and the associated thousands of waypoints which are the problem. This was a bit of a surprise although the number of waypoints I have is quite high I suppose.

Cheers

Tim

Hi Tim,

With that many waypoints, I guess they were mainly auto-numbered whilst creating routes. If that is the case, you could "Convert Route to Track" which I think would contain much less data. Later, if required, you can recover the Route with "Convert Track to Route", but the original names of any Waypoints or included Marks would be lost (so save or Lock those first).

However, note that these Route/Track conversions do not delete the originals, they are just "Hidden". So you might actually make matters worse, unless you methodically delete the "source" Tracks or Routes after conversion.

Cheers, Alan.

In the end I have gone for the less elegant solution and simply archived each of my routes by using the "save as" function to save each route in .mmo format. Then I deleted them all.

This seems to have totally circumvented the problem whereby too many routes, and hence waypoints, in the tree were slowing down basic overlay functions.

Amazing results!! Many thanks, both.

My overlay tree now opens instantaneously (20.5 Mb filesize), now that I have converted all my old routes into tracks, and have deleted the routes (along with associated waypoints).

Peviously, opening the overlay tree took almost 2 minutes (21.0 Mb filesize).

So, just a few dozen routes were causing all the delay, while my hundreds and hundreds of tracks open up instantly!

Dales.