[PROJ] 7.2.1 RC1 ob_tran changes break existing logic
kristianevers at gmail.com
Mon Dec 28 02:10:49 PST 2020
Thanks for reporting this. We certainly need to find out what’s going on here. It is possible that this change shouldn’t have been included in 7.2.1.
I can’t fully understand what you are trying to do from your code snippet below, can you provide an example that only uses PROJ tools or API?
> On 28 Dec 2020, at 10:18, Roger Bivand <Roger.Bivand at nhh.no> wrote:
> News item:
> createOperation(): make it work properly when one of the CRS is a BoundCRS of a DerivedGeographicCRS (+proj=ob_tran +o_proj=lonlat +towgs84=....) (#2441)
> appear to break:
> (crds <- matrix(data=c(9.05, 48.52), ncol=2))
> (a <- project(crds, paste("+proj=ob_tran +o_proj=longlat",
> "+o_lon_p=-162 +o_lat_p=39.25 +lon_0=180 +ellps=sphere +no_defs"),
> use_ob_tran=TRUE, verbose=TRUE))
> stopifnot(isTRUE(all.equal(a, matrix(c(-5.917698, -1.87195), ncol=2),
> tolerance=.Machine$double.eps ^ 0.25)))
> completely in the R rgdal package. ob_tran has always needed special casing, because of the reverse invert direction, but this change is a major regression. The operation on input 9.05 48.52 should return -5.917698 -1.87195 but now chooses coordOp: +proj=noop +ellps=GRS80. In
> 7.2.0, the chosen coordOp is (and probably should be):
> +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +inv +proj=ob_tran +o_proj=longlat +o_lon_p=-162 +o_lat_p=39.25 +lon_0=180 +ellps=sphere +step +proj=unitconvert +xy_in=rad +xy_out=deg
> The NEWS item does not lead one to expect this regression.
> Hope some light can be thrown on this and that release will not be rushed.
> Best wishes,
> Roger Bivand
> Department of Economics, Norwegian School of Economics,
> Helleveien 30, N-5045 Bergen, Norway.
> voice: +47 55 95 93 55; e-mail: Roger.Bivand at nhh.no
> PROJ mailing list
> PROJ at lists.osgeo.org
More information about the PROJ