[closed] Map Cache Corruption

[Yemble]

A portion of my OSGB map cache appears to be corrupted at the 1:25K zoom level, ref screenshots.

Is there a way to fix this currently, WITHOUT deleting the entire cache (I have tried re-downloading the affected area, but AQ thinks that all the tiles are current)?

If not, then will there be a method in a (near) future version of AQ?

This corruption represents a very small portion of a gigantic OSGB cache that I am building for the entire UK, which currently stands at 60Gb. As this has taken many hours and a lot of effort to build, I am HIGHLY reluctant to scrap it, so any method of repair would be welcome.

The affected area occurs as a vertical stripe and is shown by the first screenshot...

[Psyberia-Support]

Hi again,
It's unfortunately not possible to clear just a part of the storage (it won't be possible), you'll just be able to update it.
If you want to store large map areas and keep them for a while, you should use on-board maps (like .AQM), which are made to be easily managed by the user (copy from/to the device, etc).

Concerning your issue, the only way to force an update right now (it will be easy as soon as the store area will be improved), is to change the update delay of the map. I understand that you've already modified your map config file, so modify it again and add a line "<update-delay>1D</update-delay>" just before "<zoom-values>...</zoom-values>".
When re-starting the app, it will update all displayed areas. When you've done, just restore the original update delay.
I hope it will fix you storage. Let me know.

[Yemble]

Hi again,
It's unfortunately not possible to clear just a part of the storage (it won't be possible), you'll just be able to update it.
If you want to store large map areas and keep them for a while, you should use on-board maps (like .AQM), which are made to be easily managed by the user (copy from/to the device, etc).

Concerning your issue, the only way to force an update right now (it will be easy as soon as the store area will be improved), is to change the update delay of the map. I understand that you've already modified your map config file, so modify it again and add a line "<update-delay>1D</update-delay>" just before "<zoom-values>...</zoom-values>".
When re-starting the app, it will update all displayed areas. When you've done, just restore the original update delay.
I hope it will fix you storage. Let me know.

I did attempt that before, without any luck, but I may have inserted the line in the wrong place, so I will give it another go tonight. If <update-delay> is not specified at all, what value does it default to internally?

Also, for reference, if I delete one of the 2Gb cache database (DAT) files, does that break the cache completely, or will AQ just lose the contained tiles and continue to run correctly? Similar question for deleting the IDX file, does it break the cache, or does AQ rebuild the index automatically?

I would love to generate an offline map from the map cache, but there are no tools to do this currently (MOBAC is a non starter due to its chronic and outdated limitations on tile downloads). Also, my 1:50K + 1:25K OSGB map cache will be around 80Gb, once I have completed it, so I'd really need a Windows based tool to convert it to an offline map. There would not be enough storage to do this on my Android tablet, even with a 128Gb SDXC card.

So in reality, the AQ map cache in off-line mode is my ONLY (free) option for comprehensive OSGB coverage of the entire UK... unless you know different

[Psyberia-Support]

By default (if no update tag is present), the app won't refresh at all the stored data. This is good for raster topo maps which aren't updated anymore. For OSM or Google Maps, I usually configure a 1 month delay.

And do not remove a cache file by yourself, it will break the entire storage (the index is built when data is added, and is not reconstructed).

As soon as the new update is available, I'll have more time to work again on the store area tool and improve it, I'm sure we'll found a suitable solution.

[Yemble]

By default (if no update tag is present), the app won't refresh at all the stored data.

Make sense, but how does this explain the recent overwriting of OSGB tiles by BING, when no key was specified - surely these previously downloaded tiles should have been safe?

BTW, I'm still waiting for my 128Gb SDXC in order to try the 1 day fix that you suggested for the tile corruption. My current 64Gb is completely full

[Yemble]

Unfortunately, re-downloading the tiles via the 1D setting did not fix the corruption, which seems deeply embedded within the cache database. I am now pretty sure that this occurred when the SD filled during a Store Area download. My 128Gb SD has now arrived, so I have decided to re-start this map cache from scratch, but this time applying the lessons learnt from the mistakes made last time. This will probably take the best part of a week to complete

[Psyberia-Support]

but how does this explain the recent overwriting of OSGB tiles by BING, when no key was specified

You are right to assume that these maps shouldn't have been updated... If you're sure that these parts were already stored then I can't explain it. I'll double check this.

[Yemble]

but how does this explain the recent overwriting of OSGB tiles by BING, when no key was specified

You are right to assume that these maps shouldn't have been updated... If you're sure that these parts were already stored then I can't explain it. I'll double check this.

Yep, I am absolutely certain that previously downloaded OSGB tiles were overwritten, en mass, by low res BING tiles!

Note that at the time the <update>None</update> line did not exist in the map AQX file.

[Psyberia-Support]

Ok sorry then, I've just double checked and the default update delay is actually "3M", in contradiction of what I said above.
I'm now doubtful whether changing this or not... Both make sense...

Anyway mystery solved about the tiles update, and you can use "None" safely...

[Yemble]

Ok sorry then, I've just double checked and the default update delay is actually "3M", in contradiction of what I said above.
I'm now doubtful whether changing this or not... Both make sense...

Anyway mystery solved about the tiles update, and you can use "None" safely...

OK, that now makes a lot more sense - mystery solved

I agree that it is a tough call whether, or not, to disable tile updates on these large topo maps entirely, but it is good to have the option.

BTW, my newly re-created, corruption free, comprehensive OSGB map is now complete and occupies just short of 60Gb for all tiles at all zoom levels enabled in the Community Map. It took three solid days of downloading to build