python环境从3.6升级到3.7，gdal版本从2.2.4升级到3.4.1之后，执行原来的gdal脚本，结果报出如下错误

”ERROR 4: Unable to open EPSG support file gcs.csv. Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.“。

但是奇怪的是，跑出来的结果是对的。网上查了很多方法，比如设置GDAL_DATA之类的。但是我设置了之后没啥效果。

搜索了服务器上"gcs.csv",发现压根就没这个文件。

[root@1279f6fff648 project]# gdal-config --datadir

/root/miniconda3/share/gdal

[root@1279f6fff648 project]# cd /root/miniconda3/share/gdal

[root@1279f6fff648 gdal]# ls

难道gdal版本更新的过程中移除掉了这个文件?

答案确实是这样。原来gdal从2.5版本开始就将gcs.csv文件移除掉了。确切的说是proj4升级到proj6的过程中，proj6对坐标系统进行了整合，将此类信息都存储到了SQLite数据库（proj.db)中去。因此gdal也就不再存在gcs.csv文件了。

参考：

Can't find gcs.csv since release 2.4 · Issue #1471 · OSGeo/gdal · GitHub

https://trac.osgeo.org/gdal/wiki/rfc73_proj6_wkt2_srsbarn

（二）程序在GCS.csv中找不到对应的EPSG代码。

融合长势V21生产系统报出如下的错误信息。

其原因是生产系统的中有个可执行程序是基于gdal2.x版本开发编译而成的，而生产系统的环境安装的gdal版本是3.4.1。

gcs.csv文件以文本的形式记录了epsg收录的空间参考的信息。gdal在执行坐标转换、影像文件输出等操作时会读取该文件以获取空间参考信息。在gdal2版本中是有个gcs.csv这个文件的，它一般存在于gdal的安装路径.../share/gdal（如本机的路径为/root/miniconda3/share/gdal，gdal会根据GDAL_DATA这个环境变量默认读取这个路径）中。但是在gdal3版本中将这个文件取消了，取而代之的是通过本地数据库的形式记录空间参考信息。一旦报出找不到gcs.csv这种错误，可以在网上找到匹配版本的gcs.csv文件，将其拷贝到这个位置上去，使可执行程序在执行的过程中能够读取到这个文件。解决了打不开gcs.csv文件的错误，有时候会报出找不到EPSG代码的错误。比如UTM投影的代码32650，是在gcs.csv中找不到的。但是最终的结果并没有收到影响，可以忽略掉该错误或警告。

gsv.csv文件示例

"COORD_REF_SYS_CODE","COORD_REF_SYS_NAME","DATUM_CODE","DATUM_NAME","GREENWICH_DATUM","UOM_CODE","ELLIPSOID_CODE","PRIME_MERIDIAN_CODE","SHOW_CRS","DEPRECATED","COORD_SYS_CODE","COORD_OP_CODE","COORD_OP_CODE_MULTI","COORD_OP_METHOD_CODE","DX","DY","DZ","RX","RY","RZ","DS" 3819,HD1909,1024,Hungarian Datum 1909,1024,9122,7004,8901,1,0,6422,3817,0,9607,595.48,121.69,515.35,-4.115,2.9383,-0.853,-3.408 3821,TWD67,1025,Taiwan Datum 1967,1025,9122,7050,8901,1,0,6422,,0,,,,,,,, 3824,TWD97,1026,Taiwan Datum 1997,1026,9122,7019,8901,1,0,6422,3830,0,9603,0,0,0,,,, 3889,IGRS,1029,Iraqi Geospatial Reference System,1029,9122,7019,8901,1,0,6422,3894,0,9603,0,0,0,,,,

gsv.csv文件截图