Prev () | Home | Manual | () Next
(pen-pen-ultimate version - should be fine for me)
We suppose you want to keep your work save:
You will have some system and strategies in place to do backup. You want to know what, where, and when data is stored by QMapShack to include this into your existing backup, and to know what to do in case of recovery.
Basically, you have three distinct realms of storable work:
You don’t edit maps in QMapShack. Maps are huge and may eat up lots of backup resources. They may be easily recovered from the internet. Enough reason for some special considerations regarding map backup.
QMapShack reads its maps from the configured MapPaths.
Recall the map organization: DocBasicsMapDem
The essential information to backup for online maps are their definition files. They are located in your configured MapPaths.
If you installed your initial maps from the “I want maps” buttons, they are named
OpenCycleMap.tms OpenStreetMap.tms OSM_Topo.tms WorldSat.wmts WorldTopo.wmts
When browsing through maps, QMapShack maintains a local tile cache. This has limited life time and is automagically rebuilt if missing. It may contain some hundreds MB. Consider to exclude the tile cache from backup.
Default location is
~/.QMapShack/
You can change the path of the tile cache via File -> Setup Map Paths - Directly at the top of the window (“Root path of the tile cache for online maps:”).
… are usually are huge (easily some GB). They will not change while working with QMapShack. Thus you may consider them for special treatment on backup. You may keep online maps and offline maps in different paths to ease this.
.. determine how your currently visible maps - including your visible data - are displayed. Recall DocControlMapDem
The view is different and independent from your GIS data as organized in projects.
QMapShack does not save a view by default. The “File -> Store Map View” and the “File -> Load Map View” allow you to select specific locations.
It depends on your style of work, whether backing up views is worth any special consideration at all.
The project is the place where your own personal data - basically in the form of waypoints, tracks and routes - lives in. Presumably this will be the data you really want to take care of.
In terms of storage, projects may be implemented as:
See here DocHandleGpxFiles for further details on the handling of GIS files.
For both .gpx and .qms files, there is a 1:1 relation between project and file. This keeps backup procedures simple and straightforward. However, it leaves you the responsibility to keep your data in sync between different projects=files if you roll back to a different version of your work.
There is one important difference between .qms an .gpx files with regard to backup: The .qms format includes object history and allows a roll back of changes on a per object basis. This feature is not available in gpx files, because it would break the main purpose of gpx, it’s exchangeability: there is simply no standard in the gpx definitions for rollback histories.
So, if you want to combine the advantage of both worlds, save your work in a qms “master copy” (or in a database) and only produce gmx files for the sake of exchange. In the right-click context menu of the project, there is a “save as…” dialogue which allows you to switch between .gpx and .qms format for this purpose.
Databases are, like qms files, a QMapShack internal format not supposed to be disassembled by the causal end user. See here DocGisDatabase for more on databases.
In a database, multiple projects are stored in one database file. So if you backup versions of this database, all the projects within will be restored in a consistent way, if you switch to an earlier version. This means on the other hand, that you cannot easily roll back selectively. To do so, you have to open both old and new version and manually copy selected content between them as desired.
Don’t consider your mobile satnav device as a sure location for backup, even if it looks like a memory stick when you plug it into your workstation.
(The following is derived from tests with singular GARMIN nuvi and zumo units. File system organization differs not only between manufacturers, but also between device series and models. Your milegae may vary.WHAT DO YOU MEAN BY THAT?)
In the directory tree of a plugged Garmin device, you find the directory “GPX” similar to this:
This contains most information on your device as it refers to QMapShack projects. You may frequently copy them to your Workstation and include it into your backup scheme. The gpx files can be opened as QMapShack projects or any other compatible application.
We do not recommend to write directly onto the device using file level access, unless you do not know what to do. Enjoy the great work the QMS programmers have delivered and use QMapShack device access functionality instead. There are quite some items in a GPX file that the standard allows but may upset your device. You have been warned.
See here DocGisDevices for further information on device access.
We also do not discuss the other directories, as they are not immediately related to QMS work. There is a plethora of forum entries around, full of tips and good and bad experiences. Good luck trying!
There is one important thing to mention on mass storage devices: The risk of premature plugoff . In other applications, data may still reside in write cache RAM only, while the app is displaying successful writing. In Linux, you have to unmount a device, in WIN, you call “safe remove” to make sure the write cache is synced to the device.
To avoid this, QMapShack implements its own handling of device mounting. If you access a device via the icon in the workspace QMapShack will take care about mounting and unmounting the device. Simply plugin the device and wait until QMapShack recognized it. The device is unmounted unless QMapShack is actively reading/writing it (Cursor is an hourglass). Once done you can unplug the device without any further action.
This automounting of QMapShack may interfere with your OS mounting behavior and produce some warning. But following above rule, you should be on the safe side and not loose any data. If not, its time to file a bug.
The workspace is the place where QMapShack keeps your actions while you are working with it. This is distinct from the concept of project files, where your data conceptually resides before you begin after you are done.
Data in your file based projects is only stored in your files if you select “save” in the project file line’s context menu.
If you make any changes to any object (as shown here DocGisItemsEditMultiple in detail), both your edited object and the project it belongs to is marked by an asterisk * in the Data Window with the project tree:
This asterisk indicate you that your current changes are not yet written to save storage. At least not yet to the final place in the project file they belong to.
The good news: there is an periodic autosave feature for all these pending changes in your workspace. You can configure it by the menu path “Project -> setup Workspace” which gives you:
Your workspace is also saved upon clear exit of QMapShack, so all your changes you made are still available after a restart. Thus you can still continue editing, roll back to an earlier stage and/or safe your data objects finally to the project file they are supposed to belong to.
But beware - your very last changes are lost after some crash of QMapShack. There is no way to manually trigger the saving of the workspace. So if you think five minutes is too risky on your system, or for your style of work, you may decrease the value.
It is not intended that users play around with the stored workspace. So, if we provide the path here ( ~/.config/QLandkarte/ on linux systems) , this is only for backup purposes. If you need instantaneous save or consistent roll back, use one of the concepts outlined above.
The workflow for database based items is as follows: You load any project from the database by activating the associated tickbox in the database window.
Thus, it’s folder is opened as a project in the workspace with the item attached. The project name is qualified by @, followed by the parent folder in the database.
If you edit the item you will see the asterisk that it has been changed - as for file based items. If you save the project, the item will be changed in the database.
The sync. function is to update your workspace if someone else is changing items on another instance of QMapShack. This includes saving local changes and reloading all items in the workspace. On a conflict the user is asked which version to keep.