Topics

CRS & EPSG issues

geoterraimage1@...
 

(flask-cog-terracotta) PS E:\00_UBUNTU_DRIVE\WATER_MONITORING_APPLICATION> python
Python 3.7.6 | packaged by conda-forge | (default, Mar 23 2020, 22:22:21) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import rasterio
>>> rasterio.__version__
'1.1.3'
>>> from rasterio.crs import CRS
>>> crs = CRS.from_user_input("EPSG:4326")
ERROR 1: PROJ: proj_create_from_database: cannot build geodeticCRS 4326: SQLite error on SELECT name, ellipsoid_auth_name, ellipsoid_code, prime_meridian_auth_name, prime_meridian_code, area_of_use_auth_name, area_of_use_code, publication_date, deprecated FROM geodetic_datum WHERE auth_name = ? AND code = ?: no such column: publication_date
Traceback (most recent call last):
  File "rasterio\_crs.pyx", line 363, in rasterio._crs._CRS.from_user_input
  File "rasterio\_err.pyx", line 194, in rasterio._err.exc_wrap_ogrerr
rasterio._err.CPLE_BaseError: OGR Error code 6
 
During handling of the above exception, another exception occurred:
 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\jens.hiestermann\.conda\envs\flask-cog-terracotta\lib\site-packages\rasterio\crs.py", line 459, in from_user_input
    obj._crs = _CRS.from_user_input(value, morph_from_esri_dialect=morph_from_esri_dialect)
  File "rasterio\_crs.pyx", line 367, in rasterio._crs._CRS.from_user_input
rasterio.errors.CRSError: The WKT could not be parsed. OGR Error code 6
>>> crs = CRS.from_user_input("+init=epsg:4326")
Warning 1: +init=epsg:XXXX syntax is deprecated. It might return a CRS with a non-EPSG compliant axis order.
>>> 


Please assist. I am having trouble trying to locate the cause of the issue... is GDAL, PROJ, Rasterio, or the combination of them in an Anaconda environment. 

I am consistently plagued with this error msg:
 
ERROR 1: PROJ: proj_create_from_database: cannot build geodeticCRS 4326: SQLite error on SELECT name, ellipsoid_auth_name, ellipsoid_code, prime_meridian_auth_name, prime_meridian_code, area_of_use_auth_name, area_of_use_code, publication_date, deprecated FROM geodetic_datum WHERE auth_name = ? AND code = ?: no such column: publication_date
 
I have set a system variable to find the projlib proj.db in the GDAL folder but still running into the same error.
 

Even Rouault
 

> ERROR 1: PROJ: proj_create_from_database: cannot build geodeticCRS 4326:

> SQLite error on SELECT name, ellipsoid_auth_name, ellipsoid_code,

> prime_meridian_auth_name, prime_meridian_code, area_of_use_auth_name,

> area_of_use_code, publication_date, deprecated FROM geodetic_datum WHERE

> auth_name = ? AND code = ?: no such column: publication_date Traceback

 

Smells like you have PROJ 6.x.y version pointing to the proj.db of another PROJ 6.z.t version, since there were a few database schema changes. Make sure your PROJ_LIB is correctly set.

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com

geoterraimage1@...
 

On my windows PC, I am running Anaconda to handle my environments.

My guess is that the issue resides in the GDAL installation on windows, that was performed prior to installing anaconda.
PROJ_LIB was set in the system variable and pointed to the proj.db file in the GDAL folder.
If I create a new environment in Conda, and then install rasterio / gdal / geopandas, it is likely to pick up the GDAL installation currently on windows, and assume that PROJ_LIB is correct (and proj.db)? Is this likely to be leading to the error?

In terms of Conda environments and GDAL/Rasterio, should we treat each environment with its own GDAL installation and own routes to GDAL_DATA path's?

I appreciate the assistance, but how can I ensure correct environment mappings of PROJ to the proj.db that up to date with the correct db schema in the proj.db file? Is there a good rule of thumb to not stuff this up in future?

geoterraimage1@...
 

So my issue is resolved. The issue was caused by having a GDAL installation on my windows machine, as well as all the GDAL paths set up. This was conflicting with the GDAL setup in each conda environment.

I uninstalled all GDAL core and bindings from Windows itself, and then only installed GDAL in the Anaconda environment. No system variables were set after the GDAL was installed in the environment.