[PROJ] Odd 6.3.0RC1 issue
Roger Bivand
Roger.Bivand at nhh.no
Mon Dec 30 08:46:19 PST 2019
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: Roger.Bivand at nhh.no
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
More information about the PROJ
mailing list