Fix ingestion of +proj=cea with +k_0

Fixes #1881

Digging into the implementation of proj=cea, it appears that
k_0 and lat_ts are intended to be exclusive ways of specifying the
same concept. EPSG only models the variant using lat_s.
So if k_0 is found and lat_ts is absent, compute the equivalent
value of lat_ts from k_0.

Note: k_0 should normally be in the [0,1] range. In case creative users
would use something outside, we raise an exception, even if the cea
implementation could potentially deal with any k_0 value. Hopefully
this is a (reasonable) limitation that will address nominal use cases.

1 files changed, 18 insertions, 0 deletions

diff --git a/test/unit/test_io.cpp b/test/unit/test_io.cpp
index fd38847c..cc780be1 100644
--- a/test/unit/test_io.cpp
+++ b/test/unit/test_io.cpp
@@ -7968,6 +7968,24 @@ TEST(io, projparse_cea_ellipsoidal) {
 
 // ---------------------------------------------------------------------------
 
+TEST(io, projparse_cea_ellipsoidal_with_k_0) {
+    auto obj = PROJStringParser().createFromPROJString(
+        "+proj=cea +ellps=GRS80 +k_0=0.99 +type=crs");
+    auto crs = nn_dynamic_pointer_cast<ProjectedCRS>(obj);
+    ASSERT_TRUE(crs != nullptr);
+    WKTFormatterNNPtr f(WKTFormatter::create());
+    f->simulCurNodeHasId();
+    f->setMultiLine(false);
+    crs->exportToWKT(f.get());
+    auto wkt = f->toString();
+    EXPECT_TRUE(
+        wkt.find("PARAMETER[\"Latitude of 1st standard parallel\",8.1365") !=
+        std::string::npos)
+        << wkt;
+}
+
+// ---------------------------------------------------------------------------
+
 TEST(io, projparse_geos_sweep_x) {
     auto obj = PROJStringParser().createFromPROJString(
         "+proj=geos +sweep=x +h=1 +type=crs");