Test failure with Proj v5.0.1

[avalentino]

Description

I'm working to update the cartopy package in debian.
I encountered some problem trying to run the unit tests.

The issue seems to be related to some kind of incompatibility with PROJ v5.0.1 used to build the package.
See also OSGeo/PROJ#985.

Related issue #1045.

Code to reproduce

$ python2.7 -m pytest --pyargs cartopy.tests.crs cartopy.tests.test_crs cartopy.tests.test_geodesic

Traceback

============================= test session starts ==============================
platform linux2 -- Python 2.7.15, pytest-3.3.2, py-1.5.3, pluggy-0.6.0
rootdir: /home/antonio/debian/git/build-area/python-cartopy-0.16.0+dfsg1, inifile:
collected 77 items

cartopy/tests/crs/test_albers_equal_area.py ......                       [  7%]
cartopy/tests/crs/test_azimuthal_equidistant.py ........                 [ 18%]
cartopy/tests/crs/test_geostationary.py ....                             [ 23%]
cartopy/tests/crs/test_lambert_azimuthal_equal_area.py ...               [ 27%]
cartopy/tests/crs/test_lambert_conformal.py ........                     [ 37%]
cartopy/tests/crs/test_mercator.py .....                                 [ 44%]
cartopy/tests/crs/test_nearside_perspective.py ....                      [ 49%]
cartopy/tests/crs/test_robinson.py ..                                    [ 51%]
cartopy/tests/crs/test_rotated_geodetic.py .                             [ 53%]
cartopy/tests/crs/test_rotated_pole.py .                                 [ 54%]
cartopy/tests/crs/test_sinusoidal.py ....                                [ 59%]
cartopy/tests/crs/test_stereographic.py .....                            [ 66%]
cartopy/tests/crs/test_transverse_mercator.py .....F.                    [ 75%]
cartopy/tests/test_crs.py ...s.........                                  [ 92%]
cartopy/tests/test_geodesic.py ......                                    [100%]

=================================== FAILURES ===================================
____________________________ TestOSNI.test_default _____________________________

self = <cartopy.tests.crs.test_transverse_mercator.TestOSNI object at 0x7fb53d7f3410>

    def test_default(self):
        proj = ccrs.OSNI()
        res = proj.transform_point(*self.point_a, src_crs=self.src_crs)
        np.testing.assert_array_almost_equal(res, (275614.87105610,
>                                                  386984.15347340))
E       AssertionError: 
E       Arrays are not almost equal to 6 decimals
E       
E       (mismatch 100.0%)
E        x: array([275614.267627, 386984.20643 ])
E        y: array([275614.871056, 386984.153473])

cartopy/tests/crs/test_transverse_mercator.py:101: AssertionError
================ 1 failed, 75 passed, 1 skipped in 0.41 seconds ================

Operating system

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux unstable (sid)
Release:	unstable
Codename:	sid

Cartopy version

0.16.0

[pelson]

Hi @avalentino. Thanks for sharing this. It looks like proj v5 must have updated its Transverse Mercator code, including numerical accuracy differences. At first glance (I haven't reminded myself of the test code itself, so may be wrong) I couldn't say that the new results are wrong/right, and would therefore be inclined to update the test to assert that the values are approximately equal, rather than absolutely equal. Would happily take a PR that did such a thing to this test (at which point, I'd double check the provenance of the numbers being tested, just in case there is good reason to check the values should be absolutely equal to those currently written in the test).

Thanks again,

[avalentino]

@pelson yes, I can provide a patch with updated reference values.
Anyway you are already using assert_array_almost_equal so new values will presumably break tests with proj < 5 unless you also update the decimal parameter.

[pelson]

Yep, suggest updating the decimal parameter, and using the existing values.

[avalentino]

IMO it could be a temporary workaround waiting for a solution for OSGeo/PROJ#985 (cc @kbevers).

[kbevers]

I'll see if I can find the time to look at it tomorrow.