Bug report #17993: srs.db distributed with QGIS is out of date - QGIS Application - QGIS Issue Tracking

Bug report #17993

srs.db distributed with QGIS is out of date

Added by Alex Cobb almost 7 years ago. Updated over 6 years ago.

Status:	Closed
Priority:	Normal
Assignee:	-
Category:	Projection Support
Affected QGIS version:	master	Regression?:	No
Operating System:	Fedora 27, Linux 4.14.13	Easy fix?:	Yes
Pull Request or Patch supplied:	No	Resolution:	fixed/implemented
Crashes QGIS or corrupts data:	No	Copied to github as #:	25889

Description

It looks like the CRS definitions in srs.db were last updated in Feb, 2014. This does not have to be an issue in practice because running crssync will update srs.db with new CRS definitions, but crssync is not run automatically as part of a build / install from source and the need to run it manually after install is not documented in the source or on the website (searching for crssync on qgis.org yields no results, crssync does not appear in INSTALL or README.md).

The old CRS definitions in srs.db were an issue for me (Bug #12945), I have figured out a work-around (just run crssync as root user) but others might face this problem and it is not clear to a user how to fix it.

Related issues

Associated revisions

Revision 2a52a629
Added by Jürgen Fischer almost 7 years ago

osgeo4w: fix postinstall scripts (fixes #17993)

Revision 4afe9678
Added by Jürgen Fischer almost 7 years ago

run crssync on install (fixes #17993)

History

#1 Updated by Alex Cobb almost 7 years ago

I could propose three possible solutions (not mutually exclusive):
1. Have crssync run at 'make' or 'make install' stage per a patch to CMakeLists (more below).
2. Update srs.db in the QGIS sources, by running crssync with the current version of PROJ4 and re-uploading the db.
3. Document the need to run crssync after install in the sources, and file a bug with Fedora to run crssync as a post-install script (it is already part of an install / upgrade trigger in the Debian package).

I can help with pull requests / patches depending on the preferred approach.

Regarding 1, updating srs.db during make / install: I guess the easiest thing would be to run crssync at the install stage. At the build stage, although crssync does not take a file name argument, it does refer to QGIS_PREFIX_PATH, so a way to update the CRS before the install phase is (bash, from build directory):

mkdir -p share/qgis/resources
cp ../resources/srs.db share/qgis/resources
QGIS_PREFIX_PATH=$(pwd) output/bin/crssync --verbose

I am not sure how to make this cross-platform and do not have access to a Windows machine, but I could work on it with some hints. I guess that running crssync at the make install stage would be easier because it would not require this hack.

#2 Updated by Steven Mizuno almost 7 years ago

On my Windows build system srs.db is updated during building and is used if you run from the build directory. However, the updated db is not copied to the installation, nor is crssync run on the installed db.

I didn't know where the db was copied to, so I modified src/crssync/main.cpp to print the db location to be sure what was actually updated. srs.db is copied to the user's temp directory (%TEMP% in my case), then crssync is run.

I believe the srs.db file should be copied from the temp location during install or that crssync be run on the installed location.

Further testing with the OSGeo4W installer found that srs.db was not being updated during the postinstall process (I was using nightly qgis-dev). I'm not sure why at this point, as the commands in the batch file appear to be OK. And the db hadn't been updated before packaging as noticed in the build/install scenario above.

This problem is more build/install rather than projection support.