Bug report #4404

NZMG and other NZGD49 based CRSs are wrong

Added by Alister Hood almost 9 years ago. Updated over 1 year ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Projection Support
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:end of life
Crashes QGIS or corrupts data:No Copied to github as #:14336

Description

It seems that #3136 has been reverted by syncing srs.db with a faulty and unreleased (see http://trac.osgeo.org/proj/ticket/122) proj.
I presume this also affects any other CRS which is supposed to use +datum.

0001-edit-crssync-comments.patch Magnifier (2.26 KB) Alister Hood, 2011-10-21 01:40 AM

History

#1 Updated by Jürgen Fischer almost 9 years ago

  • Status changed from Open to Feedback

the srs.db is synced with GDAL on install (see crssync) - so if you're seeing bad definitions, they are probably from GDAL.

#2 Updated by Alister Hood almost 9 years ago

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.

#3 Updated by Alister Hood almost 9 years ago

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

#4 Updated by Alister Hood almost 9 years ago

I have spent some more time trying to understand this.
For the record:
- srs.db is not synced when installing from source.
- 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.
- 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!
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.

#5 Updated by Jürgen Fischer almost 9 years ago

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).

#6 Updated by Alister Hood almost 9 years ago

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.

#7 Updated by Alister Hood almost 9 years ago

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

#8 Updated by Giovanni Manghi over 8 years ago

  • Target version set to Version 1.7.4

#9 Updated by hamish - over 8 years ago

  • Affected QGIS version set to master
  • Crashes QGIS or corrupts data set to No

Hi, sorry I'm coming to this party a little late.

Alister Hood wrote:

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.

same here. this really messes things up badly for GRASS users too. (on GRASS EUR50 and NAD83 also have trouble)

I've been up to my elbows in the code and have a pretty good understanding of what's going on in the proj4/epsg file and GRASS GIS side of things (-> don't use the epsg file from proj4 svn, use the stable release 4.7.0 one instead); but I'll need to get myself up to speed on the QGIS srs.db and GDAL side of things.

regards,
Hamish
(Otago Univ.)

#10 Updated by Paolo Cavallini over 8 years ago

  • Target version changed from Version 1.7.4 to Version 1.8.0

#11 Updated by Paolo Cavallini almost 8 years ago

  • Target version changed from Version 1.8.0 to Version 2.0.0

#12 Updated by Jürgen Fischer about 6 years ago

  • Target version changed from Version 2.0.0 to Future Release - Lower Priority

#13 Updated by Giovanni Manghi about 5 years ago

  • Status changed from Feedback to Open

#14 Updated by Giovanni Manghi over 3 years ago

  • Easy fix? set to No
  • Regression? set to No

#15 Updated by Giovanni Manghi over 1 year ago

  • Status changed from Open to Closed
  • Resolution set to end of life

Also available in: Atom PDF