Gordon,
urn:ogc:def:coordinateOperation:EPSG::1311 is from ED50 to WGS84, so
what you observe with gdaltransform is expected. You'd get the correct
result by just switching EPSG:4326 and EPSG:4230
Regarding the use of the API, it is true that this was lacking. Adressed
per https://github.com/OSGeo/gdal/pull/6175
Even
Le 09/08/2022 à 13:16, Gordon Paterson a écrit :
Hi everyone,
GDAL 3.5.0
I have an application written in c# that takes data in WGS84 and
transforms the coordinates to the relevant local projected CRS.
In the code I use a URN with the EPSG transformation code, for example
for ED50 data -
urn:ogc:def:coordinateOperation:EPSG::1311
to convert between EPSG:4326 and EPSG:4230 and it works great for
going from EPSG:4230 > EPSG:4326 but it doesn't give the correct
results the other way.
Checking the coordinates with gdaltransform from the command line
using the following -
gdaltransform -s_srs EPSG:4326 -t_srs EPSG:4230 -ct
urn:ogc:def:coordinateOperation:EPSG::1311
I get this -
WGS84 (EPSG:4326)
2.25661712354279 56.4136492649363
ED50 (EPSG:4230)
2.25511244583886 56.4129769077511
which are the same coordinates I get through code, which is not
right, but with the -i switch -
gdaltransform -s_srs EPSG:4326 -t_srs EPSG:4230 -ct
urn:ogc:def:coordinateOperation:EPSG::1311 -i
I get this -
ED50 (EPSG:4230)
2.25812179682132 56.414321584992
which is correct.
In the gdal docs there is a bReverseCT boolean parameter for
SetCoordinateOperation that is not accessible and is set to always be
false in the SWIG interface.
I set the correct Axis mapping on the spatial reference within code.
I'm no doubt missing something, what am I doing wrong?
thanks very much,
-Gordon
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
