QGIS » QGIS Application

Oh, OK. I had a look at crssync, but I didn't quite understand it, and when I saw the syncs in the git log I didn't realise they aren't needed anymore.
Now I think I see, but I think there might be some issues:

1. Installing from source: when I build the INSTALL target in MS VS Express, the postinstall script must not run, as srs.db is just copied over from the QGIS source directory, and it seems there is no attempt to sync with PROJ. Should the postinstall script run when installing from source?

2. Isn't there a problem that if proj is rolled back or forward, existing QGIS installs won't update their srs.db? It would only be updated if QGIS is subsequently updated or reinstalled.

Oh, sorry, you said GDAL, not Proj. So maybe I need to rebuild Gdal.

Alister Hood wrote:

I have spent some more time trying to understand this.
For the record:
- srs.db is not synced when installing from source.

Well, I'd consider building from source something, that only developers, packagers and power users do and syncing the database is a little expensive and only needs to be done when GDAL or PROJ changes.

So if you update your GDAL, you should probably run crssync manually - or use packages that do that for you (like debian or OSGeo4W).

- srs.db is synced with gdal, not proj (so it is not the broken proj which is causing a problem). There are some comments in the source which should be changed to reflect this.

EPSG is synced with GDAL, the rest (like IGNF) with PROJ.4 (given a PROJ.4 version that doesn't crash doing that).

- What Hamish is saying in the Proj ticket is that the user should be able to choose which datum transform to use. So a standard list of CRSs using the gdal/proj default transforms may not be a very good idea!

You can use user defined CRSs for that. I agree, that's not very convienient. But those won't be altered.

Using different version of the CRS in QGIS than in OGR or proj.4 may produce (and have in the past) loads of other problems.

But:
- For some reason gdal/proj currently use the 7 parameter +towgs transforms by default. At least in the case of the nzgd49 based CRSs, using +nadgrids should produce more accurate results (within a few centimetres of the coordinates produced by the LINZ online converter). In other words, the +nadgrids options would be good defaults, which is why they were previously hand edited (I think) into srs.db
- It would really be better for GDAL and Proj to use the better default, instead of implementing it in QGIS. That way tools like ogr2ogr would by default produce the same (more accurate than currently) results as QGIS.

Yes. I agree all this is a mess. I just try to move as much as possible to the original packages (and possibly to people that understand more of it).

Jürgen Fischer wrote:

Alister Hood wrote:

I have spent some more time trying to understand this.
For the record:
- srs.db is not synced when installing from source.

Well, I'd consider building from source something, that only developers, packagers and power users do and syncing the database is a little expensive and only needs to be done when GDAL or PROJ changes.

So if you update your GDAL, you should probably run crssync manually - or use packages that do that for you (like debian or OSGeo4W).

OK, but this should probably be mentioned in the INSTALL file.

- srs.db is synced with gdal, not proj (so it is not the broken proj which is causing a problem). There are some comments in the source which should be changed to reflect this.

EPSG is synced with GDAL, the rest (like IGNF) with PROJ.4 (given a PROJ.4 version that doesn't crash doing that).

Thanks for the explanation.

- What Hamish is saying in the Proj ticket is that the user should be able to choose which datum transform to use. So a standard list of CRSs using the gdal/proj default transforms may not be a very good idea!

You can use user defined CRSs for that. I agree, that's not very convienient. But those won't be altered.

I will manually edit my srs.db now that I know about the problem. But it is everyone else in the country that I am worried about.
I'll see if the LINZ guys agree that this is something that should be changed in gdal/proj, and try to move the discussion upstream.

If anyone is coming to this cold, some of the history of the syncing can be found at #3645