Hi, thanks again for the explanation
I uploaded the tif file I was trying to render here: https://www.virtual-winds.org/maitai/gebco.tif The thing that worries me is that it is the first case since we upgraded to 3.4.1 a quite a while ago, and I am wondering how it can work for all other tif datasets we are using. I tested a few with this modification and nothing seems broken, so it seems OK. --Philippe ________________________________ From: gdal-dev <[email protected]> on behalf of Laurențiu Nicola via gdal-dev <[email protected]> Sent: Tuesday, October 18, 2022 3:45 PM To: [email protected] Subject: Re: [gdal-dev] Problem with coordinate transformation Hi, According to the migration guide, this is only relevant for OSRImportFromEPSG, SetWellKnownGeogCS and SetFromUserInput. But then again, you were using the equivalent of OSRImportFromWkt. I never noticed any issues when using spatial references loaded from existing rasters, but you might want to test. I tried loading the SpatialReference from a NetCDF produced by GDAL 2.3.2, under the (verified) assumption that it will contain the SRS without the AXIS nodes. But GDAL 3.5.1 still seems to use the traditional order for these. Laurentiu On Tue, Oct 18, 2022, at 15:39, Philippe Lelong wrote: Thanks very much, I would never have figured that out myself. Just to make it clear I should add this flag on all OGRSpatialReference or only when it is loaded with importFromWkt ? --Philippe ________________________________ From: gdal-dev <[email protected]> on behalf of Laurențiu Nicola via gdal-dev <[email protected]> Sent: Tuesday, October 18, 2022 1:01 PM To: [email protected] Subject: Re: [gdal-dev] Problem with coordinate transformation Hi Philippe, The new behaviour is correct. See https://gdal.org/development/rfc/rfc73_proj6_wkt2_srsbarn.html#axis-order-issues for the axis order issue, a change made in GDAL 3.0. You can find a solution in https://github.com/OSGeo/gdal/blob/v3.5.0/MIGRATION_GUIDE.TXT#L67 (calling SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER) on every OGRSpatialReference you use. Laurentiu On Tue, Oct 18, 2022, at 13:43, Philippe Lelong wrote: Hi, I have an app build against GDAL 3.4.1 and PROJ6, and the same app build against GDAL 2.1.3 and PROJ4. They are not giving the same result when using OGRCoordinateTransformation. If I do const char *their = "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0],UNIT[\"degree\",0.0174532925199433],AUTHORITY[\"EPSG\",\"4326\"]]"; const char *our = "+proj=longlat +datum=WGS84 +ellps=WGS84 +no_defs +over"; double miX = -17.4042; double miY = 35.3333; OGRSpatialReference theirReference; theirReference.importFromWkt((char**)&their); OGRSpatialReference ourReference; ourReference.importFromProj4(our); OGRCoordinateTransformation *trans = OGRCreateCoordinateTransformation(&theirReference, &ourReference); trans->Transform(1, &miX, &miY); in the version build against GDAL 3.4.1/PROJ6 this code results in swapping miX and miY (i.e. miX = 35.3333 and miY = -17.4042) The version build against GDAL 2.1.3/PROJ4 leaves miX and miY unchanged, which I believe is correct. Any explanation for this behavior and which one is correct? Would I get the same result using PROJ8 ? Thanks in advance Philippe Lelong _______________________________________________ gdal-dev mailing list [email protected]<mailto:[email protected]> https://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list [email protected]<mailto:[email protected]> https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
