<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 gmail_quote_container"><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">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>