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
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
