From f201a86386b9c8fa183b3f9855a4087a9a800f4e Mon Sep 17 00:00:00 2001 From: Even Rouault Date: Sat, 25 Jan 2020 16:31:00 +0100 Subject: 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. --- test/unit/test_io.cpp | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'test/unit/test_io.cpp') 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(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"); -- cgit v1.2.3