Feature request #3136

Update NZ projections for grid transformation support

Added by Jeremy Palmer about 14 years ago. Updated over 10 years ago.

Status:Closed
Priority:Low
Assignee:Jürgen Fischer
Category:Projection Support
Pull Request or Patch supplied:No Resolution:
Easy fix?:No Copied to github as #:13196

Description

This SQL update script modifies the srs.db proj4 parameters so that the NZGD49<->NZGD2000 transformation grid is used. Also in the case when the grid is not found the lower accuracy 7 parameter transformation is used.

This is a follow on to r14399.

See http://www.linz.govt.nz/geodetic/conversion-coordinates/geodetic-datum-conversion/nzgd1949-nzgd2000/index.aspx for more information

qgis_nzgd49_proj4_updates.sql (9.79 KB) Jeremy Palmer, 2010-10-19 04:46 PM

History

#1 Updated by Jürgen Fischer about 14 years ago

  • Status changed from Open to Closed
  • Resolution set to fixed

applied in . Thanks Jeremy.

#2 Updated by Alister Hood about 13 years ago

  • Pull Request or Patch supplied set to No

Hi Jeremy,
Are you aware that when QGIS is installed now (unless installing from source) the srs.db is automatically synced with gdal and proj, so the transformation grid is not used anymore (unless a user sets up custom projections)?
See #4404.

I think that when a transformation grid is present gdal and proj should really use it by default (not just QGIS). You and Hamish both seem to have spent some time grappling with this issue, so perhaps you could comment?

Thanks

#3 Updated by Jeremy Palmer about 13 years ago

Hi Alister,

I think the best option is to patch NZGD49 based proj.4 and gdal definitions upstream so that the nzgd2kgrid0005.gsb grid is used by default and then fallback to the 7 parameter xform if the grid is not found.

Here at LINZ we promote the distortion grid as the default method for shifting between the NZGD2k and NZ49 datums. The only reason to fall back to the 3 and 7 parameters methods is due to limitations in software (which is not the case with proj.4)

Cheers
Jeremy

#4 Updated by Jeremy Palmer about 13 years ago

BTW: I've looked at this issue before and it does seem like there isn't an easy fix.

As far as I can see the proj4 epsg config file is updated from the EPSG database using an translation script (which frank W maintains, which I have not seen the code for). The EPSG database does not store information about distortion grids and only has 3 a 7 parameter data. So I believe the translation script would need to be updated to include these additional grids.

In terms of gdal there is another problem as the coordinate system storage does seem to support the grid files at all (see datum_shift.csv). So that would also need to be improved along with the code that reads that data and converts the OGRSpatialReference to a proj.4 string. Maybe someone on the gdal list could comment more about this...

#5 Updated by hamish - almost 13 years ago

Hi,

sorry I didn't see this bug report earlier, I've mainly just been paying attention to the GRASS side of things.

One possible problem on MS Windows is that the osgeo4w support library for proj4 is shipping the development 4.7.1svn version instead of the stable 4.7.0 version.
see https://trac.osgeo.org/osgeo4w/ticket/217

I'm not sure if Frank generates GDAL's srs files from the upstream EPSG database directly, or if his scripts first generate the proj4 files then make a second pass to make the GDAL ones. (.. and then AFAIU qgis generates theirs from the GDAL ones) perhaps the order of that doesn't matter as the result is the same.

the main part that frustrates me with the epsg file is that the +datum parts have been removed so you can't even do a lookup to see that it possible to opt out of the 7-term parameters. (n.b. +towgs84 and +nadgrids are incompatible, make sure to edit instead of appending)

anyway, I will look into this more over the coming weeks and see what we can work out in gdal/proj4 as the entire osgeo stack is affected by this.

Hamish
(Otago Univ.)

#6 Updated by hamish - over 10 years ago

  • Resolution deleted (fixed)

by the way, the 7 term transform is the default probably because things go weird once you go beyond the edge of the grid. (of course NZMG goes weird after you get out of sight of land too, and really weird even further out into the ocean, but near to east cape and southern fiordland it's quite easy to fall of the edge of the transform grid)

for what it's worth, qgis 2.2 on debian/wheezy currently gives me this for NZMG:

+proj=nzmg +lat_0=-41 +lon_0=173 +x_0=2510000 +y_0=6023150 +ellps=intl
 +towgs84=59.47,-5.04,187.44,0.47,-0.1,1.024,-4.5993 +units=m +no_defs

2c,
Hamish

Also available in: Atom PDF