[gdal-dev] Upgrading to GDAL 3.4.2 from 1.10.0 shows different outputs from gdaltransform and corresponding C++ API

[Even Rouault]

Le 10/09/2024 à 02:55, Fox, Shawn D (US) via gdal-dev a écrit :
> Evan,
>
> Thanks for putting some time into that response and showing some examples.  Perhaps I should clarify exactly how our software is using GDAL.  I thought that it was easier to show the problem using gdaltransform rather than source code, but that does lack some context.  Here is crude, but simple example of how the C Apis are being used.
> --- source code begin ---
> OGRSpatialReferenceH sourceSRS = OSRNewSpatialReference(NULL);
> OGRSpatialReferenceH targetSRS = OSRNewSpatialReference(NULL);
>
> errorSource = OSRSetWellKnownGeogCS( sourceSRS, "NAD27");
> errorTarget = OSRSetWellKnownGeogCS( targetSRS, "WGS84");
>
> OGRCoordinateTransformationH ptrCT = OCTNewCoordinateTransformation( sourceSRS, targetSRS );
> status = OCTTransform( ptrCT, 1, x_lon, y_lat, NULL );

Source code speaks for itself :-) This is a CRS axis order issue. Cf 
https://gdal.org/en/latest/tutorials/osr_api_tut.html#crs-and-axis-order 
for the whole discussion

With your current code and GDAL >= 3, the input axis order should be 
(lat, lon) since NAD27 in EPSG is declared as (lat, lon) ordered and 
GDAL 3 honours that by default

If you want to keep long, lat axis order, add 
OSRSetAxisMappingStrategy(errorSource, OAMS_TRADITIONAL_GIS_ORDER); and 
OSRSetAxisMappingStrategy(errorTarget, OAMS_TRADITIONAL_GIS_ORDER); 
before creating the coordinate transformation

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240910/eb7d2bba/attachment.htm>