Adding proj-datumgrid-nz (New Zealand) grids to oceania

[ccrook]

This adds grids for New Zealand to the proj-datumgrid-oceania distribution.

These files are also available at https://github.com/linz/proj-datumgrid-nz and for download as a zip file from https://www.geodesy.linz.govt.nz/download/proj-datumgrid-nz.

Note: this duplicates the NTv2 grid file for NZGD49 to NZGD2000 conversion (nzgrid2k0005.gsb) which is also included in the base proj-datumgrid repository. This sensibly belongs in the oceania grids, but due to its long history is located in the general distribution. It is left there to avoid breaking users of this grid. Note use of NZGD49 is "deprecated" in New Zealand, so the usage of this grid is expected to decrease over time.

[ccrook]

Note: The alternative grid names are for proj-datumgrid-nz are not yet installed in the proj grid_alternatives.sql file.

[kbevers]

@ccrook Thanks for adding the NZ grids, they are a valuable ressource for users of PROJ and downstream projects. Please follow the format used in the other regional packages. That is, put the relevant information in README.OCEANIA in a New Zealand section and remove the various *.proj-datumgrid-nz files. I understand the desire to have as little maintenance as possible on your part but by submitting your data here in a non-standardized way increases the maintenance burden for the PROJ project. It also makes it more complicated for users to easily get an overview of what is included in the package.

[ccrook]

@kbevers @rouault Thanks for comments. @kbevers - no problem with removing the files and combining the README, and I certainly was not trying to create a greater maintenance burden. I didn't think it would do that :-( Mainly I was feeling that we can expect a lot more grids in the future as PROJ has become a tool for geodetic transformations and as the expectations of accuracy and time based transformations increase. Also for time based transformations the rate of updates to grids (or generation of new grids) may increase as we look to respond more rapidly to deformation events.

So my reasoning was 1) I was aiming to have a proj-datumgrid-nz for NZ users as that could provide a clearer separation of responsibilities between the geodetic agency responsible for developing and maintaining the transformations, and 2) the additional proj-datumgrid-nz files would provide a structured link to the source agency.

Also this follows from a discussion https://lists.osgeo.org/pipermail/proj/2019-November/009047.html suggesting that we could develop a simple installer for grid packages, so I was thinking these files would provide the information necessary for installing and maintaining a grid package (or maybe for harvesting to a CDN).

However that is just one of many possible futures! If you still feel that this is not useful and creates work I'll remove them.

[hobu]

I was aiming to have a proj-datumgrid-nz for NZ users as that could provide a clearer separation of responsibilities

After some consideration, I also think that we the proj-datumgrid should organize, manage, and release the grids according to responsible agency rather than any kind of geography. The agencies implicitly define a geography in many but not all cases.

[rouault]

Regarding the structure of the repository, I've opened a dedicated discussion in https://github.com/OSGeo/proj-datumgrid/issues/74. As it might depend on PROJ RFC4, I'd suggest in the meantime that LINZ datasets go into -oceania for now, and we'll potentially reorganize in a later step.

[ccrook]

@kbevers Following discussion above please could you confirm if you still feel removing proj-datumgrid-nz files and combining README is preferred for users/maintainers?

[kbevers]

@kbevers Following discussion above please could you confirm if you still feel removing proj-datumgrid-nz files and combining README is preferred for users/maintainers?

Yes, I think that is preferable for now. I am generally in favour of the proposal in #74 but we still have a 6.3 release to put about before that can become a reality.

[rouault]

@ccrook Are you going to work on addressing the comments ? The 6.3 release is planned Jan 1st. The https://github.com/OSGeo/proj-datumgrid-geotiff/ repository for 7.0 should be a better home for the future :-)

[ccrook]

Yes .. had hoped to today. Will definitely do tomorrow first thing NZ time

Thanks Chris

---

From: Even Rouault [notifications@github.com] Sent: Wednesday, 18 December 2019 11:10 a.m. To: OSGeo/proj-datumgrid Cc: Chris Crook; Mention Subject: Re: [OSGeo/proj-datumgrid] Adding proj-datumgrid-nz (New Zealand) grids to oceania (#69)

@ccrookhttps://github.com/ccrook Are you going to work on addressing the comments ? The 6.3 release is planned Jan 1st. The https://github.com/OSGeo/proj-datumgrid-geotiff/ repository for 7.0 should be a better home for the future :-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/OSGeo/proj-datumgrid/pull/69?email_source=notifications&email_token=AAE2CETWL4ZR4LL77DST3VLQZFE5HA5CNFSM4JUQNJM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHEEBGA#issuecomment-566771864, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAE2CEQTBBGMG5X37UI453LQZFE5HANCNFSM4JUQNJMQ.

---

This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info@linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.

[rouault]

I was attending the IOGP geodesy subcomittee meeting and NZ case was discussed. So the trend would be to create new method for the vertical offset, deprecate the existing transformations, and create new transformations using the new method. And for the geoid models, deprecate the existing transformation and add new ones likely using the existing GTX one. But pending such an EPSG update is done and we resynchronize for it, I think we can live with what exists currently in proj.db One thing that was mentionned during the meeting and that I wasn't fully aware if that there's some potential confusion / error on the vertical offset transformations of New Zealand ? I'd assume that if going from source vertical CRS to target vertical CRS, the grid should contain the offset to add.

[rouault]

Would you mind also registring the grids in filelist.csv at the root of the repository (so they can be automatically converted in GeoTIFF by my https://github.com/rouault/sample_proj_gtiff_grids/blob/master/convert_all.py script ?)

[ccrook]

The grids do contain the offset to add. I also heard this and have checked it. I wonder if this confusion came from using the grids as if they were geoid grids (in which case they are the wrong way).

In relation to IOGP pending updates I'm wondering how to proceed with the two pull requests on PROJ relating to this.

https://github.com/OSGeo/PROJ/pull/1766 maps the current EPSG grid names to the proposed .gtx names. This becomes redundant when the EPSG updates come into force.

https://github.com/OSGeo/PROJ/pull/1770 adds support for the current NZ transformation method. This would be updated to use the new GTX method (just changing the EPSG code and name). The proposed test code is based on EPSG may won't work if it gets updated...

(And yes - will update filelist.csv)

[rouault]

The grids do contain the offset to add.

OK, what is confusing is the filenames: "auckland-1946-to-nzvd2016-conversion.csv" for a transformation called 'NZVD2016 height to Auckland 1946 height (1)'. So for double checking, to convert from NZVD2016 height to Auckland 1946 height, one adds the value found in the .csv/.gtx file, right ?

[ccrook]

The grids do contain the offset to add. OK, what is confusing is the filenames then "auckland-1946-to-nzvd2016-conversion.csv" for a

Yes, that the filenames were pretty awful - not sure what the history on that is. The new files names are auckht1946-nzvd2016.gtx, which you can read as auck height minus nzvd height, ie to be added to convert NZVD2016 to AUCKHT etc. They are done that way round as the auck bit is most significant in terms of the use of the file. The names are briefer to make it easier for users entering on a command line (and also consistent with some other usage in LINZ)

[rouault]

@kbevers I'm rather happy with this PR, and you ? There's just one detail that bothers me a bit: the duplication of the nzgd2kgrid0005.gsb grid in -ocenia whereas it is already in main package. Someone unzipping both will probably get a warning about the duplication and if they want to overwrite or not, and they might be confused. I do think that the nzgd2kgrid0005.gsb grid should be removed from -oceania for now (@ccrook sorry, yesterday I didn't realize that you had duplicated the .gsb itself. I thought you were just mentioning it only in the README file)

[ccrook]

You sold me with the comment on this being the last version using proj-datumgrid-oceania :-) Duplicate grid is now removed from oceania ...

[rouault]

I'm happy with how it looks. Merging

[rouault]

Grids converted & integrated to proj-datumgrid-geotiff repository per https://github.com/OSGeo/proj-datumgrid-geotiff/commit/f10e1753f05b6bfc820c535fdc0e5ef34410b203