<div dir="ltr"><div>GDAL (via PROJ) is honoring the axis order of the CRS, except if OAMS_TRADITIONAL_GIS_ORDER is set.<br></div>In your case, the output in ESG:4326 is lat-lon, as expected. If you want anything else, yes, it is your responsibility.</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, 1 Apr 2026 at 18:11, Florian Katerndahl <<a href="mailto:florian@katerndahl.com">florian@katerndahl.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>Hi Javier,</p>
<p>I apologize for not being clear enough and the mess of numbers
below.</p>
<p>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:<br>
POLYGON ((365696.917646939 5840653.27654771,364734.337580538
5794593.87120464,419979.831606673 5793998.8089232,413446.242115242
5838664.50707989,365696.917646939 5840653.27654771)).<br>
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:<br>
POLYGON ((52.6991111242901 13.0124564576972,52.2850386029731
13.01693061834,52.2905122538779 13.8267536946937,52.6909763323844
13.7193738392656,52.6991111242901 13.0124564576972)).<br>
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).</p>
<p>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?</p>
<p>Kind regards,</p>
<p>Florian</p>
<div>On 4/1/26 17:22, Javier Jimenez Shaw
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>EPSG:4326 is lat-lon, EPSG:5556 is easting-northing-up.</div>
<div>I don't see where is your problem.</div>
<div>It would be easier if you provide some numbers and tell
exactly what you expect (with numbers).</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, 1 Apr 2026 at 17:14,
Florian Katerndahl via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi
Even,<br>
<br>
thanks for your reply.<br>
<br>
I don't pass the coordinates directly via `OCTTransform` but
use <br>
`OGR_GeomTransformer_Transform` to transform polygon
geometries. Based <br>
on the fact than when fetching the points that make up the
input <br>
polygon, the x and y coordinates match the axis of the input
CRS, my <br>
assumption was that I don't need to change the ordering for
the input <br>
CRS. Looking at the points in the output geometry, the
coordinates are <br>
flipped when not setting OAMS_TRADITIONAL_GIS_ORDER. This was
the reason <br>
why I assumed I need to set the axis ordering depending on the
CRSs I <br>
translate between.<br>
<br>
But if I understand your reply correctly, I should also not
need to <br>
touch the axis ordering for the output CRS as GDAL takes care
of mapping <br>
the data to CRS axis for the output geometry. I suppose my
understanding <br>
is not sufficient enough (yet) to understand the underlying
issue then <br>
and I will need to do some further research on my side.<br>
<br>
<br>
Kind regards,<br>
<br>
Florian<br>
<br>
<br>
On 4/1/26 16:26, Even Rouault wrote:<br>
><br>
> Le 01/04/2026 à 16:04, Florian Katerndahl via gdal-dev a
écrit :<br>
>> Dear all,<br>
>><br>
>> I'm currently working on a small program which allows
users to <br>
>> specify vector inputs in different coordinates
systems and that <br>
>> potentially "normalizes" them to EPSG:4326 internally
to process them <br>
>> further. Maybe I'm too inexperienced and there's an
easy solution but <br>
>> I got hung up on the coordinate transformation when
the input CRS has <br>
>> a different axis ordering compared to the output CRS
using <br>
>> GDAL's/OGR's C API.<br>
>><br>
>> For example, transforming between EPSG:5556 and
EPSG:4326, GDAL <br>
>> outputs a warning (forwarded from proj?) that the
output's latitude <br>
>> is invalid. Setting the axis ordering of the target
CRS to <br>
>> `OAMS_TRADITIONAL_GIS_ORDER` fixes this and results
in correctly <br>
>> located polygons. My question is now: Is it
sufficient/correct to <br>
>> compare the axis ordering of the input and output
coordinate systems <br>
>> and set above mentioned flag (or a custom mapping
when neither <br>
>> "x"/"y" are the first two axis) in case they differ?<br>
><br>
> The axis ordering of the input CRS vs the one of the
output CRS is <br>
> complelely unrelated w.r.t your decision about setting or
not <br>
> OAMS_TRADITIONAL_GIS_ORDER. Setting it or not for the
input totally <br>
> depends on your decision how you want to specify the
coordinates.<br>
><br>
><br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote></div>