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.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
