Silent @null gridshift failure for points outside -180º/+180º

[proj4-bot]

Reported by rcoup on 3 Jun 2009 02:15 UTC
Following on from http://trac.osgeo.org/gdal/ticket/2994

Test case is attached against trunk r1583.

Basic problem:

• transform: (165.9134918212895400 -47.7347488403320312, 165.9134918212895400 -34.2310752868652344, 184.6205993652343977 -34.2310752868652344, 184.6205993652343977 -47.7347488403320312, 165.9134918212895400 -47.7347488403320312)
• from: +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs
• to: +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs
• end up with points[- points[4](0].x).x == -3.7252902984619141e-09 != 0.0 (which then results in a not-closed polygon)

What i've dug up:

• The @null gridshift isn't quite null:
  (2.8957367057621863 + 3.1415926535897931 - 3.1415926535897931) - 2.8957367057621863 == -4.4408920985006262e-16 != 0 nad_cvt.c:13 & nad_cvt.c:57
• The @null gridshift fails for points outside +180/-180 longitude.
• Then the failure is treated as a transient error (pj_transform.c:638) and returns a success code, so 1/2 the points are gridshifted (ie. slightly-not-0 change) and 1/2 are not (ie. 0 change).

Questions:

• Is the @null gridshift meant to fail for points outside +180/-180? nad_cvt() seems to normalise values back into a 2PI range anyway, so maybe it can be ignored?
• Should the gridshift failure be silently dropped?
• This particular case only happens to fail using Proj's DEG_TO_RAD (0.0174532925199432958) which is different from OGC's (0.0174532923199433) which GDAL uses... just to make it more fun.
• As an aside (for nad_cvt()'s normalising), in adjlon(), ONEPI * 2.0 != TWOPI...

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

[proj4-bot]

Comment by warmerdam on 9 Feb 2012 04:27 UTC
Q1: Is the @null gridshift meant to fail for points outside +180/-180?

A1: No, this is not intentional. It would be preferrable to have the null file extended.

Q2: Should the gridshift failure be silently dropped?

A2: Hmm, tough to answer. It is now reported via logging, but otherwise it gets lost as some other transient errors do. The really right thing to do would be to set points that fail to shift to HUGE_VAL to mark them as corrupt but that is pretty severe and I hesitate to do that. It will gum things up for lots of situations that would reasonably well now.

I have changed pj_apply_gridshift.c to not stop the loop when one point falls outside the grid shift area to ensure more consistent behavior. I've also made a note in the code about how we could make falling outside the grid shift area more severe. Changes in trunk (02ac444d (SVN rev2153)).

[proj4-bot]

Comment by rcoup on 9 Feb 2012 21:09 UTC

"low value" points on the fringes of some
datasets will completely fail causing lots of problems when it is more
or less ok to just not apply a datum shift. So rather than deal with
that we just fallback to no shift. (see also bug #45).

I think this is only ok for the @null case (where any shift is minimal anyway) or if we fall back to 3/7 param transforms (see #19) - otherwise not doing a datum shift at all could easily make the result hundreds of metres out?

[proj4-bot]

Comment by warmerdam on 9 Feb 2012 21:24 UTC
Robert,

My theory is that "falling off the edge of the grid" will normally only occur in large scale datasets in which the datum shift is not really all that important anyways. You can certainly define ERR_GRID_AREA_TRANSIENT_SEVERE to ensure we don't accidentally think data off the grid was handled properly.

I'm still not willing to commit to using towgs84 transformations as a fallback.

You might want to raise this issue on the mailing list to get broader feedback on the least worst solution.

[proj4-bot]

Attachment added by rcoup on 3 Jun 2009 02:16 UTC
https://trac.osgeo.org/proj/attachment/ticket/45/prec_proj.c