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

GDAL (via PROJ) is honoring the axis order of the CRS, except
if OAMS_TRADITIONAL_GIS_ORDER is set.
In your case, the output in ESG:4326 is lat-lon, as expected. If you want
anything else, yes, it is your responsibility.

On Wed, 1 Apr 2026 at 18:11, Florian Katerndahl <[email protected]>
wrote:

> 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