chamb projects control points incorrectly

[brsr]

The projected value of the control points calculated by the chamb projection can be wildly different from nearby points. This seems to only happen at exactly the control points. It is more noticeable when the control points are more widely spaced: with the points used in the docs, the deviation is smaller. See the example below, based on the control points 22°N 0°, 22°N 45°E, 22°S, 22.5°E (as in the Wikipedia article) and points offset from those by +/- 1° in latitude or longitude. You can see just by looking at the numeric values that the projected value at those points is off by a factor of 2 or more compared to nearby points. I've observed this on Mac OS X and Windows 7, both with PROJ version 6.2.0.

Points written to a file called projchamtest.txt :

-1 21
-1 22
-1 23
0 21
0 22
0 23
1 21
1 22
1 23
21.5 -23
21.5 -22
21.5 -21
22.5 -23
22.5 -22
22.5 -21
23.5 -23
23.5 -22
23.5 -21
44 21
44 22
44 23
45 21
45 22
45 23
46 21
46 22
46 23

And its transformation:

$ proj +proj=chamb +lat_1=22 +lon_1=0 +lat_2=-22 +lon_2=22.5 +lat_3=22 +lon_3=45 < projchamtest.txt 
-575288.22	2397195.66
-587903.88	2388781.65
-600683.86	2380387.35
-581991.24	2405077.40
-2736433.73	4193225.00
-607326.84	2388516.93
-588569.60	2412975.26
-601131.38	2404810.21
-613851.64	2396658.49
-353966.01	2579553.86
-251127.95	2796292.68
-258718.53	2792562.59
-266436.55	2788773.14
-252518.33	2799057.89
2736433.73	4193225.00
-267972.65	2791849.37
-253743.50	2801900.15
-261479.30	2798481.40
-269342.48	2795003.16
-353966.01	2579553.86
-764282.35	2789685.46
-778610.74	2785307.85
-793030.77	2780800.26
-766106.18	2799801.03
-780545.43	0.00
-795075.73	2791031.40
-767837.54	2810001.75
-782391.31	2805742.85
-797035.57	2801345.38

[brsr]

I think this might be a more pervasive issue? See the below Python script (it uses geopandas, which uses pyproj, which is a thin wrapper for PROJ). It produces a map of Africa that seems to taper as it goes south, ending in a point at South Africa. Compare the result to the image used on Wikipedia, which doesn't have that distortion.

import geopandas
import matplotlib.pyplot as plt

world = geopandas.read_file(geopandas.datasets.get_path('naturalearth_lowres'))
africa = world[world.continent == 'Africa']
projdict = {'proj':'chamb',
            'lon_1':45, 'lat_1':22,
            'lon_2':0, 'lat_2':22,
            'lon_3':22.5, 'lat_3':-22}
projafrica = africa.to_crs(projdict)
fig, ax = plt.subplots(figsize=(10, 10))
projafrica.plot(color='black', ax=ax)
plt.show()

[rouault]

I don't think the issue is in PROJ. At least for your use case. The order of control points seem to matter. If you use the one given by https://en.wikipedia.org/wiki/Chamberlin_trimetric_projection, then you should use
+proj=chamb +lat_1=22 +lon_1=0 +lat_2=22 +lon_2=45 +lat_3=-22 +lon_3=22.5
And using that I get a correct display of Africa

[brsr]

This projection does work correctly if the control points are given in clockwise order: the initial problem I had with the control points themselves being projected strangely also goes away.

Nowhere in the documentation on proj.org, either on the page for the chamb projection or elsewhere on the site, is it indicated that clockwise would be the correct orientation for the control points. I'm not sure whether clockwise or counterclockwise is more prevalent as the "usual" orientation: I notice that the area calculation in the geodesic calculations uses counterclockwise triangles, and another OSGeo project GEOS seems to prefer counterclockwise.

I would suggest one or more of the following:

1. Add a line to chamb's documentation saying that it expects points in clockwise order.
2. Raise an error or warning when chamb is called with control points in counterclockwise orientation.
3. If chamb is called with control points in counterclockwise orientation, reverse them (and issue a warning). (I don't believe anyone would want to actually use the behavior of this projection in opposite orientation, but I'm no expert.)

Not sure which solution would be best.

[kbevers]

1. Add a line to chamb's documentation saying that it expects points in clockwise order.

This is the correct way to deal with this issue. The projection has been part of PROJ for close to an eternity and we shouldn't change the behaviour unless it is proven to be incorrect. It would be very helpful if you can open a pull request with your suggestion to improvements of the docs.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.