Re: Coordinate transformation of geometries between CRSs with different axis ordering (C API)

Hi Javier,

I apologize for not being clear enough and the mess of numbers below.

a sample input polygon in EPSG: 5556 is comprised of the coordinates: x: 
365696.917647, y: 5840653.276548, x: 364734.337581, y: 5794593.871205, 
x: 419979.831607, y: 5793998.808923, x: 413446.242115, y: 
5838664.507080, x: 365696.917647, y: 5840653.276548 or as WKT:
POLYGON ((365696.917646939 5840653.27654771,364734.337580538 
5794593.87120464,419979.831606673 5793998.8089232,413446.242115242 
5838664.50707989,365696.917646939 5840653.27654771)).
Transforming this to EPSG:4326 results in the following: x: 52.699111, 
y: 13.012456, x: 52.285039, y: 13.016931, x: 52.290512, y: 13.826754, x: 
52.690976, y: 13.719374, x: 52.699111, y: 13.012456 and again as WKT:
POLYGON ((52.6991111242901 13.0124564576972,52.2850386029731 
13.01693061834,52.2905122538779 13.8267536946937,52.6909763323844 
13.7193738392656,52.6991111242901 13.0124564576972)).
The expected output is however: POLYGON ((13.0124564576972 
52.6991111242901,13.01693061834 52.2850386029731,13.8267536946937 
52.2905122538779,13.7193738392656 52.6909763323844,13.0124564576972 
52.6991111242901)). The latter I achieve when setting 
OAMS_TRADITIONAL_GIS_ORDER on the target CRS (EPSG:4326).

Maybe phrasing my question differently is more correct: When 
using OGR_GeomTransformer_Transform to transform geometries, am I 
correct in the assumption that it's my responsibility to make sure the 
x/y coordinates stored in the supplied OGRGeometryH object are stored in 
the order the source CRS expects them according to its data-to-axis 
mapping and that if this ordering differs from what EPSG:4326 defines, 
set OAMS_TRADITIONAL_GIS_ORDER on the target CRS?

Kind regards,

Florian

On 4/1/26 17:22, Javier Jimenez Shaw wrote:
> EPSG:4326 is lat-lon, EPSG:5556 is easting-northing-up.
> I don't see where is your problem.
> It would be easier if you provide some numbers and tell exactly what 
> you expect (with numbers).
>
> On Wed, 1 Apr 2026 at 17:14, Florian Katerndahl via gdal-dev 
> <[email protected]> wrote:
>
>     Hi Even,
>
>     thanks for your reply.
>
>     I don't pass the coordinates directly via `OCTTransform` but use
>     `OGR_GeomTransformer_Transform` to transform polygon geometries.
>     Based
>     on the fact than when fetching the points that make up the input
>     polygon, the x and y coordinates match the axis of the input CRS, my
>     assumption was that I don't need to change the ordering for the input
>     CRS. Looking at the points in the output geometry, the coordinates
>     are
>     flipped when not setting OAMS_TRADITIONAL_GIS_ORDER. This was the
>     reason
>     why I assumed I need to set the axis ordering depending on the CRSs I
>     translate between.
>
>     But if I understand your reply correctly, I should also not need to
>     touch the axis ordering for the output CRS as GDAL takes care of
>     mapping
>     the data to CRS axis for the output geometry. I suppose my
>     understanding
>     is not sufficient enough (yet) to understand the underlying issue
>     then
>     and I will need to do some further research on my side.
>
>
>     Kind regards,
>
>     Florian
>
>
>     On 4/1/26 16:26, Even Rouault wrote:
>     >
>     > Le 01/04/2026 à 16:04, Florian Katerndahl via gdal-dev a écrit :
>     >> Dear all,
>     >>
>     >> I'm currently working on a small program which allows users to
>     >> specify vector inputs in different coordinates systems and that
>     >> potentially "normalizes" them to EPSG:4326 internally to
>     process them
>     >> further. Maybe I'm too inexperienced and there's an easy
>     solution but
>     >> I got hung up on the coordinate transformation when the input
>     CRS has
>     >> a different axis ordering compared to the output CRS using
>     >> GDAL's/OGR's C API.
>     >>
>     >> For example, transforming between EPSG:5556 and EPSG:4326, GDAL
>     >> outputs a warning (forwarded from proj?) that the output's
>     latitude
>     >> is invalid. Setting the axis ordering of the target CRS to
>     >> `OAMS_TRADITIONAL_GIS_ORDER` fixes this and results in correctly
>     >> located polygons. My question is now: Is it sufficient/correct to
>     >> compare the axis ordering of the input and output coordinate
>     systems
>     >> and set above mentioned flag (or a custom mapping when neither
>     >> "x"/"y" are the first two axis) in case they differ?
>     >
>     > The axis ordering of the input CRS vs the one of the output CRS is
>     > complelely unrelated w.r.t your decision about setting or not
>     > OAMS_TRADITIONAL_GIS_ORDER. Setting it or not for the input totally
>     > depends on your decision how you want to specify the coordinates.
>     >
>     >
>     _______________________________________________
>     gdal-dev mailing list
>     [email protected]
>     https://lists.osgeo.org/mailman/listinfo/gdal-dev
>

_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev