Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fallback to 7/3 param transform when gridshift transform fails #19

Closed
proj4-bot opened this issue May 22, 2015 · 11 comments
Closed

fallback to 7/3 param transform when gridshift transform fails #19

proj4-bot opened this issue May 22, 2015 · 11 comments

Comments

@proj4-bot
Copy link

Reported by cdestigter on 4 Nov 2008 21:08 UTC
Posted to proj user list on 16 April 08:

We came across some out-of-grid geometries when transforming from EPSG:27200 (New Zealand Map Grid). The results returned included INFs and NANs, which was hardly useful.

As a solution I wrote a patch for the pj_datum_transform function in Proj. The patch first tries to convert coordinates using the gridshift approach if available, but on failure will fall back to using the appropriate 3- or 7-parameter transform.

I've updated the patch to a universal diff and attached it to this ticket.

Comment from the original post ( hamish_b at yahoo dot com ):
Yes, the distortion grid hugs the coast quite closely in places.
(regardless of file size issues, it's based on trig stations, so that's hardly surprising)

I've experienced this in GRASS when plotting a lat/lon grid over a NZMG location with the 'd.grid -g' or 'ps.map geogrid' modules. I had to switch to the 7 term transform to get it to work. But then at a scale where you're going far offshore switching away from the grid probably doesn't make any difference. (for me it was just ~10-20km west of Fiordland when it failed)

NZMG distortion gets very bad (totally wonky) far away from the main coasts, if your data is from like the Kermadec, Chatham, or Auckland Islands I think you probably should try hard to use something else. (somewhen I made a screenshot of that)

One worry I have with the patch is that it makes the data of uneven quality across the dataset. (but again NZMG/NZGD1949 is pretty much ???? at sea anyway, so maybe who cares?)

regards,
Hamish

Dept Marine Science
University of Otago

Migrated-From: https://trac.osgeo.org/proj/ticket/19

@proj4-bot
Copy link
Author

Comment by cdestigter on 4 Nov 2008 21:21 UTC
second patch removes some unnecessary stuff which shouldn't have been in the first patch (porting artifacts from cvs to svn)

@proj4-bot
Copy link
Author

Comment by rcoup on 5 Jul 2009 10:41 UTC
I've attached a reworked patch: The goals were to:

  1. fallback to 3/7 parameter transforms for source points outside the grid range
  2. happily work for point sequences. ie. if point 5/10 failed it would use 3/7 param, while the other 9 points would use the grid.

The 2nd is a problem currently, since the gridshift bails out with a "transient error", so the return code from pj_datum_transform() ends up being 0 even though there were errors and many points weren't transformed. Postgis deliberately checks for this and throws an exception. See also #45.

Changes in the patch:

  • make a projection's datum_type a mask, so it can have 3param & 7param & gridshift rather than only one.
  • make a new -47 error for pj_apply_gridshift, which is transient and is returned only when a point is outside the grid range (as opposed to -38 which is also used for file-not-found, etc).
  • make -38 not transient.
  • make apply-gridshift take/return an array which it populates with 0 (transformed successfully) or 1 (errors) for each point processed.
  • if a -47 error occurs during the gridshift, transform the errored points via 3/7 param before continuing with the remainder of the datum transformation.
  • handling only a subset of points required changes to the APIs of several functions. I've maintained the old public APIs and used "funcname_impl()" for the ones that take an ignore-mask. The _impl versions aren't in proj_api.h (and only 1 was needed in projects.h)

My main test case ([attachment:proj_grid_test.c]) was transforming:

3010000.0,5300000.0
1990000.0,6790000.0 # outside the gridshift range
3010000.0,5300000.0

between:

+proj=nzmg +lat_0=-41 +lon_0=173 +x_0=2510000 +y_0=6023150 +ellps=intl +datum=nzgd49 +units=m +no_defs +nadgrids=nzgd2kgrid0005.gsb

and:

+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs

@proj4-bot
Copy link
Author

Comment by rcoup on 20 Jul 2009 06:20 UTC
Updated patch & testcase fixes an issue where double-datum transforms occurred when projections had both 7/3 and gridshift transforms defined.

@proj4-bot
Copy link
Author

Attachment added by cdestigter on 4 Nov 2008 21:09 UTC
https://trac.osgeo.org/proj/attachment/ticket/19/datum_gridshift_fallback.diff

@proj4-bot
Copy link
Author

Attachment added by cdestigter on 4 Nov 2008 21:20 UTC
https://trac.osgeo.org/proj/attachment/ticket/19/datum_gridshift_fallback2.diff

@proj4-bot
Copy link
Author

Attachment added by rcoup on 5 Jul 2009 10:26 UTC
https://trac.osgeo.org/proj/attachment/ticket/19/datum_gridshift_fallback.4.diff

@proj4-bot
Copy link
Author

Attachment added by rcoup on 5 Jul 2009 10:43 UTC
https://trac.osgeo.org/proj/attachment/ticket/19/proj_grid_test.c

@proj4-bot
Copy link
Author

Attachment added by rcoup on 20 Jul 2009 06:21 UTC
https://trac.osgeo.org/proj/attachment/ticket/19/datum_gridshift_fallback.5.diff

@proj4-bot
Copy link
Author

Attachment added by rcoup on 20 Jul 2009 06:22 UTC
https://trac.osgeo.org/proj/attachment/ticket/19/proj_grid_test.2.c

@proj4-bot
Copy link
Author

Attachment added by rcoup on 27 Jul 2009 22:37 UTC
https://trac.osgeo.org/proj/attachment/ticket/19/datum_gridshift_fallback.6.diff

@busstoptaktik
Copy link
Member

Closing, since attachment links now 404

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants