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
