Re: Odd 6.3.0RC1 issue
Roger Bivand <[email protected]> Mon, 30 Dec 2019 17:46:19 +0100
| Newsgroups | gmane.comp.gis.proj-4.devel |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 30 Dec 2019, Even Rouault wrote: > On lundi 30 décembre 2019 16:50:24 CET Roger Bivand wrote: >> Having installed 6.3.0RC1 and built GDAL 3.0.2 and GDAL master against it, >> I'm seeing a possible regression in GDAL function exportToProj4() after >> instantiating with EPSG:27700. With 6.2.1 I see "+proj=tmerc +lat_0=49 >> +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +units=m >> +no_defs" but with 6.3.0RC1 and both GDAL versions "+proj=tmerc +lat_0=49 >> +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +no_defs". The >> offending code is on R-Forge at: >> https://r-forge.r-project.org/scm/viewvc.php/pkg/R/ogr_sp.R?view=markup&root >> =rgdal function showSRID(), calling C++ function P6_SRID_show() at >> https://r-forge.r-project.org/scm/viewvc.php/pkg/src/ogr_proj.cpp?view=marku >> p&root=rgdal. >> >> In the failing case, importFromEPSG() seems to work, but for 6.3.0RC1, the >> string exported to Proj4 has lost +ellps= and +units=. >> >> I imagine that this is my mistake, but help would be appreciated. > > Perhaps make sure PROJ_LIB is correctly set up / that you point to the > right proj.db There is only one in /usr/local/share/proj/proj.db, it is not that. > > Things work correctly for me: > > $ projinfo EPSG:27700 -o PROJ > PROJ.4 string: > +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +units=m +no_defs +type=crs > This also worked for me, but is only in PROJ, not in PROJ and GDAL. > $ gdalsrsinfo EPSG:27700 -o PROJ4 > > +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +units=m +no_defs > Having re-made GDAL against 6.3.0RC1 to check this, yes, I see the same with pkg-config proj --modversion 6.3.0 & gdal-config --version 3.1.0. Speculation, does using SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER) make a difference? I'm setting this without checking to see whether the CRS is already in this order, but turning this off has no effect. I have to ensure that R sp-based legacy workflows stay easting-northing in all circumstances, sf workflows going forward may pivot to authority compliance. Anyway, rgdal is definitely broken with 6.3.0RC1 with no +ellps=airy term, and no +units=m term after exportToProj4(). What is the name of +ellps to use with GDALs OGRSpatialReference GetAttrValue()? Then I can check that it is present in the input node (must be there). Roger > Even > > -- Roger Bivand Department of Economics, Norwegian School of Economics, Helleveien 30, N-5045 Bergen, Norway. voice: +47 55 95 93 55; e-mail: [email protected] https://orcid.org/0000-0003-2392-6140 https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en _______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj