[gdal-dev] Problem with coordinate transformation

[Philippe Lelong]

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 <gdal-dev-bounces at lists.osgeo.org> on behalf of Laurențiu Nicola via gdal-dev <gdal-dev at lists.osgeo.org>
Sent: Tuesday, October 18, 2022 3:45 PM
To: gdal-dev at lists.osgeo.org
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 <gdal-dev-bounces at lists.osgeo.org> on behalf of Laurențiu Nicola via gdal-dev <gdal-dev at lists.osgeo.org>
Sent: Tuesday, October 18, 2022 1:01 PM
To: gdal-dev at lists.osgeo.org
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
gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/gdal-dev


_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/gdal-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20221018/34f2a047/attachment.htm>