[gdal-dev] OGR GeoJSON transormation woes
hallo at frankbroniewski.com
Thu May 7 02:52:31 PDT 2020
thank you very much for the hint. Although after researching on it I
fell into a rabbit hole and just barely got out, but with a decent
Why do these coordinate systems and their axes have to be so
complicated, they make my head hurt ... :-)
For future readers on the topic of coordinate systems, axes and the
order of things, there is a nice Wiki article on the OSGeo website,
aptly named Axis Order Confusion  where you can read about the stuff,
follow the links and get a headache too :-)
Onwards to the solution of my problem, which I want to share of course.
Even's hint suggested to look at the axis ordering of the LUREF CRS,
which is "northing (X)" and then "easting (Y)". Reading  more
carefully might have given me already a hint about what to do, since the
"Starting with GDAL 3.0, the axis order mandated by the authority
defining a CRS is by default honoured by the OGRCoordinateTransformation
class, and always exported in WKT1"
which should have lead me to the conclusion that EPSG:2169 also has the
axes swapped. And if my memory would have served me better, I once knew
this fact as well.
Well, apparently all I needed to to was to tell my target
SpatialReference to honour OAMS_TRADITIONAL_GIS_ORDER as well:
is all that was needed ...
But after reading all this stuff, I wonder if it would not have been
better/more right to "correct" the GeoJSON coordinate order from Lon/Lat
to Lat/Lon so that it matches the definition of EPSG:4326? I will have
to think about how to deal with geo data and the treatment of CRS in
future projects. Simply setting SetAxisMappingStrategy where it may fit
does not seem to be a very thought-out and future proof process in the end.
is the API documentation for Python up to date? The SpatialReference
docs  are missing the SetAxisMappingStrategy method
More information about the gdal-dev