Yes, I only happened to have an answer ready to go because I looked into it myself after seeing the same!
Playing around a bit more, it looks like all of the issues stem from an original error with creating crsGeo, deriving from Proj being unable to match EPSG prog_type is: >>> proj_type = 123456789 >>> crsGeo.ImportFromEPSG(proj_type) ERROR 1: PROJ: proj_create_from_database: crs not found 6 This then results in a null transform being created: >>> t = osgeo.osr.CoordinateTransformation(crs, crsGeo) ERROR 1: PROJ: proj_create: unrecognized format / unknown name ERROR 1: Cannot instantiate target_crs ERROR 6: Cannot find coordinate operations from `EPSG:27700' to `' >>> t <osgeo.osr.CoordinateTransformation; proxy of None > And I then receive the same (slightly misleading) error about the call arguments being incorrect: >>> (lat, long, z) = t.TransformPoint(posX, posY) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "…/lib64/python3.6/site-packages/osgeo/osr.py", line 1104, in TransformPoint return _osr.CoordinateTransformation_TransformPoint(self, *args) NotImplementedError: Wrong number or type of arguments for overloaded function 'CoordinateTransformation_TransformPoint'. Possible C/C++ prototypes are: OSRCoordinateTransformationShadow::TransformPoint(double [3]) OSRCoordinateTransformationShadow::TransformPoint(double [4]) OSRCoordinateTransformationShadow::TransformPoint(double [3],double,double,double) OSRCoordinateTransformationShadow::TransformPoint(double [4],double,double,double,double) (I suspect the error might originate from SWIG being unable to match the call for a None/null object, rather than a CoordinateTransform?) Dr Daniel Evans Software Developer e: daniel.ev...@jbarisk.com t: +44 (0)1756 799919 www.jbarisk.com All JBA Risk Management's email messages contain confidential information and are intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. JBA Risk Management Limited is registered in England, company number 07732946, 1 Broughton Park, Old Lane North, Broughton, Skipton, North Yorkshire, BD23 3FD, England. From: Paul Harwood <rune...@gmail.com> Sent: 16 June 2021 10:17 To: Daniel Evans <daniel.ev...@jbarisk.com> Cc: zerovirus123 <briansi...@gmail.com>; gdal-dev <gdal-dev@lists.osgeo.org> Subject: Re: [gdal-dev] TypeError Wrong number or type of arguments for overloaded function 'CoordinateTransformation_TransformPoint'. I admit - I was just working from the nerror message ... F:\Sliding_Windows\GeoTiff.py, line 402: TypeError Wrong number or type of arguments for overloaded function 'CoordinateTransformation_TransformPoint'. Possible C/C++ prototypes are: OSRCoordinateTransformationShadow::TransformPoint(double [3]) suggests that it is looking for 3 coords On Wed, 16 Jun 2021 at 10:02, Daniel Evans <daniel.ev...@jbarisk.com<mailto:daniel.ev...@jbarisk.com>> wrote: However - I think you need three input coords on the transform point? The Swig bindings for Python [should/used to] provide a wrapper for TransformPoint(), of the form TransformPoint(x, y, z=0.0) in Python terms. It’s one of the listed bindings on the Python API documentation: TransformPoint(CoordinateTransformation self, double x, double y, double z=0.0) https://gdal.org/python/osgeo.osr.CoordinateTransformation-class.html Looking at the autogenerated SWIG source code in the latest version of the repository, it looks like that particular wrapper still exists: SWIGINTERN void OSRCoordinateTransformationShadow_TransformPoint__SWIG_2(OSRCoordinateTransformationShadow *self,double argout[3],double x,double y,double z=0.0){ if (self == NULL) return; argout[0] = x; argout[1] = y; argout[2] = z; OCTTransform( self, 1, &argout[0], &argout[1], &argout[2] ); } https://github.com/OSGeo/gdal/blob/master/gdal/swig/python/extensions/osr_wrap.cpp#L4422 I’ll admit none of that particularly helps solve the issue beyond saying “I think it should work”, though! Dr Daniel Evans Software Developer e: daniel.ev...@jbarisk.com<mailto:daniel.ev...@jbarisk.com> t: +44 (0)1756 799919<tel:+44%20(0)1756%20799919> www.jbarisk.com<http://www.jbarisk.com/> [cid:image001.png@01D7629B.5F790AA0] [Facebook]<https://www.facebook.com/TheFloodPeople> [LinkedIn]<https://www.linkedin.com/company/jba-risk-management/> [Twitter]<https://twitter.com/JBARisk> [YouTube]<https://www.youtube.com/channel/UC0iatom2jYbW96voW0rlpCw> All JBA Risk Management's email messages contain confidential information and are intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. JBA Risk Management Limited is registered in England, company number 07732946, 1 Broughton Park, Old Lane North, Broughton, Skipton, North Yorkshire, BD23 3FD, England. From: gdal-dev <gdal-dev-boun...@lists.osgeo.org<mailto:gdal-dev-boun...@lists.osgeo.org>> On Behalf Of Paul Harwood Sent: 16 June 2021 09:52 To: zerovirus123 <briansi...@gmail.com<mailto:briansi...@gmail.com>> Cc: gdal-dev <gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>> Subject: Re: [gdal-dev] TypeError Wrong number or type of arguments for overloaded function 'CoordinateTransformation_TransformPoint'. Some ideas for you: - In the conda environment - it says that Fiona and GDAL come from the pipwin channel. I would try importing them from the conda-forge channel since I think that is more actively maintained (and by the core teams). This should do the trick conda install -c conda-forge fiona Also the same for pyproj conda install -c conda-forge pyproj Pyproj and OSR can work in the same app - I am doing that. You do have to be a bit careful about remembering that the SR objects are not interchangeable. - in the conda environment if it working correctly - you should NOT have to worry about proj - the correct version is and environment variables are loaded automatically as part of the activate command. Indeed - having other versions of proj.dll in the PATH will just confuse things - try removing them and any env variables set OUTSIDE of the conda activate command. I think that all of those errors are caused by this error: C:\Users\Deployment\.conda\envs\sw_py37_cv45\Library\share\proj\proj.db lacks DATABASE.LAYOUT.VERSION.MAJOR / DATABASE.LAYOUT.VERSION.MINOR metadata. It comes from another PROJ installation However - I think you need three input coords on the transform point? That command says that it is getting proj from an environment called sw_py_cv45. Just to ask the obvious question ... That is the environment that you 3expect to be using ..correct? The error does suggest that the environment is corrupted and the version of proj.dll in the env (or being found by the Python installed in the env) is not the same as the version of the proj.db in the share directory of the env. If it was me - I would probably start again from scratch - i.e. conda create --name test conda activate test conda install -c conda-forge fiona conda install -c conda-forge pyproj and see what you get. Just as a BTW - it looks like you have a custom config of Anaconda - since conda usually puts the env directory in a directory called `anaconda3`. Are you sure that the conda config is correct? On Wed, 16 Jun 2021 at 05:42, zerovirus123 <briansi...@gmail.com<mailto:briansi...@gmail.com>> wrote: I am trying to run some GDAL operations inside my Anaconda environment. However once I upgraded my gdal and other packages the program crashed. Environment: Anaconda Package Version Channel GDAL 3.3.0 pipwin fiona 1.8.20 pipwin geopandas 0.9.0 pipwin shapely 1.7.1 pipwin pyproj 2.6.1.post1 py37hcfa1391_1 Here is the offending code. crsGeo = osgeo.osr.SpatialReference() crsGeo.ImportFromEPSG(int(proj_type)) t = osgeo.osr.CoordinateTransformation(crs, crsGeo) (lat, long, z) = t.TransformPoint(posX, posY)<------------------- srs = osgeo.osr.SpatialReference(wkt=prj) And the raster's metadata. /proj: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9122"]], AXIS["Latitude",NORTH], AXIS["Longitude",EAST], AUTHORITY["EPSG","4326"]] proj type: 4326/ The code threw the following error. *ERROR 1: PROJ: proj_create_from_database: C:\Users\Deployment\.conda\envs\sw_py37_cv45\Library\share\proj\proj.db lacks DATABASE.LAYOUT.VERSION.MAJOR / DATABASE.LAYOUT.VERSION.MINOR metadata. It comes from another PROJ installation. ERROR 1: PROJ: proj_create_from_database: C:\Users\Deployment\.conda\envs\sw_py37_cv45\Library\share\proj\proj.db lacks DATABASE.LAYOUT.VERSION.MAJOR / DATABASE.LAYOUT.VERSION.MINOR metadata. It comes from another PROJ installation. ERROR 1: PROJ: proj_create: unrecognized format / unknown name ERROR 6: Cannot find coordinate operations from `GEOGCRS["WGS 84",DATUM["World Geodetic System 1984",ELLIPSOID["WGS 84",6378137,298.257223563,LENGTHUNIT["metre",1]]],PRIMEM["Greenwich",0,ANGLEUNIT["degree",0.0174532925199433]],CS[ellipsoidal,2],AXIS["latitude",north,ORDER[1],ANGLEUNIT["degree",0.0174532925199433]],AXIS["longitude",east,ORDER[2],ANGLEUNIT["degree",0.0174532925199433]],ID["EPSG",4326]]' to `' Could not calculate crsGeo spatial reference. F:\Sliding_Windows\GeoTiff.py, line 402: TypeError Wrong number or type of arguments for overloaded function 'CoordinateTransformation_TransformPoint'. Possible C/C++ prototypes are: OSRCoordinateTransformationShadow::TransformPoint(double [3]) OSRCoordinateTransformationShadow::TransformPoint(double [4]) OSRCoordinateTransformationShadow::TransformPoint(double [3],double,double,double) OSRCoordinateTransformationShadow::TransformPoint(double [4],double,double,double,double)* Based on previous posts, it seems that proj.dll is missing from some PATH variable. My environment only has a proj_6_2.dll, and even with that added to my system's PATH, the error persists. I have tried to put posX and posY inside tuples/list as well, but that did not help. Is this a package mismatch issue? Missing dependencies issue? Or was there a change in how TransformPoint should be called? -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org> https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev