[gdal-dev] OGR GeoJSON transormation woes

[Even Rouault]

On mercredi 6 mai 2020 16:27:24 CEST Frank Broniewski wrote:
> Hi everybody,
> 
> I've written a small plugin for QGIS in which I am using OGR to
> transform GeoJSON from a Web API into a national CRS.
> It used to work fine, but the changes introduced to axis ordering with
> the latest versions of GDAL introduced errors in my code. Things aren't
> anymore where they are supposed to be :-)
> 
> 
> The GeoJSON I receive is in LON/LAT coordinate ordering:
> "coordinates": [6.1409004235, 49.6127108119]
> 
> The projected coordinates in LUREF/EPSG:2169 are:
> "coordinates": [ 78032.625859561609104, 75343.040142811907572 ]
> 
> 
> An here is what I have tried so far:
> # correctly transformed geometry X/Y (LUREF epsg:2169)
> # used to perform the test
> target_geom = ogr.CreateGeometryFromJson('{ "type": "Point",
> "coordinates": [ 78032.625859561609104, 75343.040142811907572 ] }')
> 
> # source geometry with LON/LAT coordinates
> ogr_geom = ogr.CreateGeometryFromJson('{"coordinates": [6.1409004235,
> 49.6127108119], "type": "Point"}')
> 
> source_srs = osr.SpatialReference()
> source_srs.SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER)
> source_srs.ImportFromEPSG(4326)
> 
> target_srs = osr.SpatialReference()
> target_srs.ImportFromEPSG(2169)
> 
> transformation = osr.CoordinateTransformation(source_srs, target_srs)
> ogr_geom.Transform(transformation)
> 
> # test if equal /w unittest
> self.assertEqual(target_geom.ExportToWkt(), ogr_geom.ExportToWkt())
> 
> 
> So basically I imported the GeoJSON, created a transformation and
> applied it to the input geometry. The last line is just a test, the
> output from the test is as followed:
> 
> - POINT (78032.6258595616 75343.0401428119)
> + POINT (75343.0401428119 78032.6258595616)
> 
> As you can see the transformed geometry still has the coordinate order
> mixed up, but the numbers are already right with
> OAMS_TRADITIONAL_GIS_ORDER. I have searched quite a bit, stumbled over
> https://gdal.org/tutorials/osr_api_tut.html but I am out of wits here now.

Well, you are quite close to the solution by having spotted the existence of 
OAMS_TRADITIONAL_GIS_ORDER. The next step is that you look at the axis order reported 
by "gdalsrsinfo EPSG:2169", and you should figure out the solution :-)


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200506/0d467149/attachment-0001.html>