[PROJ] Fwd: Bug in the file proj.db

[Even Rouault]

Olaf,

(Forwarding/replying to the list, but you should subscribe to the mailing list 
in order to post.)

The alias you mention are coming from ESRI and are thus the "official" name to 
be used for WKT to put in shapefile .prj files.

Trying with recent GDAL (3.2) and PROJ (7.2), I don't get any round-tripping 
issue.

$ ogr2ogr -a_srs EPSG:31467 out.shp poly.shp
$ gdalsrsinfo -e out.shp | grep "EPSG:"
EPSG:31467

Presumably something has been fixed since the PROJ version you use, likely the 
logic in PROJ to "identify" a WKT string to a known CRS from the database. I 
although suspect this might perhaps come from your QGIS version: I don't 
remember if 3.4 was fully ready to deal with latest PROJ versions. You'd be 
better with 3.10 or later.

Even

On mercredi 4 novembre 2020 19:29:44 CET Olaf Willenbrock wrote:
> second try of my e-mail
> 
> 
> -------- Weitergeleitete Nachricht --------
> Betreff: Bug in the file proj.db
> Datum: Wed, 4 Nov 2020 18:07:49 +0100
> Von: Olaf Willenbrock <mail at olafwillenbrock.de>
> An: proj at lists.osgeo.org
> 
> 
> Hello,
> 
> I think I found a bug in the file proj.db. I am using the version of
> GDAL 3.1.3 from https://gisinternals.com/release.php
> In the file proj.db there is a table called "alias_name". If you start
> the following query:
> select * from "alias_name" where code like "3146%"
> 
> you will find nine coordinate reference systems with the codes 31461 to
> 31469. They are used in Germany. The five CRS 31461 to 31465 are
> deprecated. The four CRS 31466 to 31469 are valid.
> 
> The nine records are:
> table_name    auth_name    code    alt_name    source
> projected_crs    EPSG    31461    DHDN_3_Degree_Gauss_Zone_1    ESRI
> projected_crs    EPSG    31462    DHDN_3_Degree_Gauss_Zone_2    ESRI
> projected_crs    EPSG    31463    DHDN_3_Degree_Gauss_Zone_3    ESRI
> projected_crs    EPSG    31464    DHDN_3_Degree_Gauss_Zone_4    ESRI
> projected_crs    EPSG    31465    DHDN_3_Degree_Gauss_Zone_5    ESRI
> projected_crs    EPSG    31466    DHDN_3_Degree_Gauss_Zone_2    ESRI
> projected_crs    EPSG    31467    DHDN_3_Degree_Gauss_Zone_3    ESRI
> projected_crs    EPSG    31468    DHDN_3_Degree_Gauss_Zone_4    ESRI
> projected_crs    EPSG    31469    DHDN_3_Degree_Gauss_Zone_5    ESRI
> 
> The text in the field "alt_name" is "DHDN_3_Degree_Gauss_Zone_[x]" where
> [x] is a number from 1 to 5. The text for the valid CRS is wrong (I
> think). The word "Kruger_" is missing. It must be
> "DHDN_3_Degree_Gauss_Kruger_Zone_[x]".
> 
> If you look at the table "projected_crs" in the file proj.db you can
> find this nine records:
> 
> auth_name    code    name    deprecated
> EPSG    31461    DHDN / 3-degree Gauss zone 1    1
> EPSG    31462    DHDN / 3-degree Gauss zone 2    1
> EPSG    31463    DHDN / 3-degree Gauss zone 3    1
> EPSG    31464    DHDN / 3-degree Gauss zone 4    1
> EPSG    31465    DHDN / 3-degree Gauss zone 5    1
> EPSG    31466    DHDN / 3-degree Gauss-Kruger zone 2    0
> EPSG    31467    DHDN / 3-degree Gauss-Kruger zone 3    0
> EPSG    31468    DHDN / 3-degree Gauss-Kruger zone 4    0
> EPSG    31469    DHDN / 3-degree Gauss-Kruger zone 5    0
> 
> The names of the valid CRS contains "Kruger".
> 
> I found this bug by using ogr2ogr and QGIS (3.4.8). If you run this
> command with a valid EPSG:
> ogr2ogr.exe -t_srs EPSG:31467 output.shp input.shp
> 
> and open the output.shp in QGIS and look at the file properties you can
> find this:
> EPSG:31463 - DHDN / 3-degree Gauss zone 3 (deprecated)
> This is wrong. This is the wrong EPSG number.
> 
> The prj file contains the text "DHDN_3_Degree_Gauss_Zone_3".
> 
> Now I have modified the file proj.db and added the missing text
> "Kruger_" and run the command again. Now the prj file contains the text
> "DHDN_3_Degree_Gauss_Kruger_Zone_3" and QGIS is showing:
> EPSG:31467 - DHDN / 3-degree Gauss-Kruger zone 3
> This is the correct EPSG number.
> 
> Can you please verify if this is a bug and if the file proj.db is the
> problem? Perhaps the problem is more complicate and other files are
> responsible.
> 
> Best regards
> 
> Olaf


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com