CRS information not recognized when geopackage is loaded

Question

I am starting to transition from .shp to geopackage data format in QGIS. There are many benefits to the format that give it an advantage over shapefile for many of my projects. However, I am having a recurring issue. When ever I load a previously saved geopackage file into QGIS, the program does not recognize the CRS and defaults it to that of the project. I then have to go into the properties and change the CRS to the appropriate system. I have tried updating the metadata for the layer but this does not help. What can I do to ensure that CRS information is included with the geopackage?

Geopackaging process- To create a geopackage I use the Export tool found when one right clicks on a layer in the QGIS "Layers" panel. I then select Geopackage as the file type and set the CRS for the saved file. The source files are generally in CSV or .shp or .tab(Mapinfo). The issue seems to occur regardless of the file type.

Answer 1

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://epsg.org/search/by-name.

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.