[gdal-dev] Problem with coordinate transformation

Laurențiu Nicola lnicola at dend.ro
Tue Oct 18 06:45:01 PDT 2022


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


More information about the gdal-dev mailing list