QGIS is made to use Write Ahead Logging (WAL) by commit https://github.com/qgis/QGIS/commit/f939e9cff598b95e95b0de099d0c9a92eed0ea9c
The new behavior should be to open gpkg database file in WAL journal mode if file is on local disk but turn it back to the default journal mode when the connection is closed.
I made a test with QGIS 2.18.2 and that seems to work. I opened a gpkg database with "Add Vector Layer" and immediately -wal and -shm files appear in the same directory. When I removed the layer from QGIS both files disappear. I verified with spatialite-gui that the journal mode was really turned back by making a pragma request
PRAGMA journal_mode;
You must not ever delete manually -wal and -shm files. If they still are there in the directory I would check if there are any other clients than QGIS having connections. If not, opening and closing db with QGIS may clear the temporary files and turn logging to default mode. If that does not help, try with the pragma command
PRAGMA journal_mode=DELETE;
It is not possible to turn the journal mode from WAL to anything else if there are any other open connections. Only the last connection can do the change. Also, journal mode is persistent and gpkg database that is set to WAL mode remains in WAL mode until it is explicitly set to something else. I guess that this may cause troubles sometimes. I made this simple test:
- Open a gpkg that is originally in journal_mode=delete with QGIS -> journal mode turns into WAL
- Open the same gpkg with spatialite-gui -> journal mode is still WAL
- Close the layer from QGIS -> journal mode is WAL in spatialite-gui
- Close gpkg from spatialite-gui -> the -wal and -shm files disappear but journal mode remains WAL
In this state the gpkg database will work from local disk but not from network drives if copies of it are given to end users!
Edit:
These are the two ways reported by Even Roualt for turning WAL mode off from QGIS:
People can either define the OGR_SQLITE_JOURNAL environment variable
to DELETE or set the QGIS setting "/qgis/walForSqlite3" (in advanced
mode) to false, and this will prevent QGIS from enabling WAL on
opening. The drawback is potential deadlocks in some situations where
a reader and writer would run concurrently.
I don't know how QGIS writes and reads CRS information, but currently there is a significant issue with non-EPSG codes.
A short answer to how to know if your file has a valid CRS defined, until this problem is resolved, is to verify if the code is registered in https://www.epsg-registry.org/.
If the code is registered, the file will have a valid CRS. If not, no.
Some time ago I had been observing that I had many custom CRSs automatically generated, but I did not know what was due and I thought it was normal. Until I saw this question. Since then I began to investigate a little about the subject, with my limited academic resources in computer subjects.
Note the following behaviors from the console:
C:\>cs2cs -v +init=epsg:102711
Using from definition: init=epsg:102711
Rel. 5.2.0, September 15th, 2018
<cs2cs>:
projection initialization failure
cause: invalid projection system error (-9999)
program abnormally terminated
C:\>cs2cs -v +init=esri:102711
# ---- From Coordinate System ----
#Transverse Mercator
# Cyl, Sph&Ell
# +init=esri:102711 +proj=tmerc +lat_0=38.83333333333334 +lon_0=-74.5
# +k=0.999900 +x_0=150000 +y_0=0 +ellps=GRS80 +datum=NAD83
# +to_meter=0.3048006096012192 +no_defs +towgs84=0,0,0
#--- following specified but NOT used
# +ellps=GRS80
# ---- To Coordinate System ----
#Lat/long (Geodetic alias)
#
# +proj=latlong +datum=NAD83 +ellps=GRS80 +towgs84=0,0,0
^C
In the proj
database this is an Esri code, and it is defined in the .\share\proj\esri
file.
The WKTs written by QGIS for these CRSs are not recognized as valid at the time of reading.
In a shapefile, the WKT is written in the .qpj file, and the last line says: AUTHORITY["Esri","102711"]
. If that line were changed by AUTHORITY["EPSG","102711"]
, the file would have a valid CRS for QGIS. In Linux are written a little different, I imagine that another version of a library will be installed. But is invalid too.
In a geopackage, the WKT is written in the definition field of the gpkg_spatial_ref_sys table. Yo can see it from Database > DB Manager > SpatiaLite > New Connection connecting to the geopackage. The attribute can be updated by SQL queries. But I do not intend to manually edit each written attribute in a way that can not be read as valid, that is, the CRS of each file that does not correspond to an EPSG code.
I would rather have it resolved by the developers. This bug ticket was opened at the time. Contributions and details that I do not know and can be corrected, are welcome.
Best Answer
I do not know how QGIS deals with metadata but I think that the best way to do that with GeoPackages would be to follow the standard
GDAL has limited support for metadata in GeoPackage https://www.gdal.org/drv_geopackage.html