Re: Performance issue in coordinate transformations with Gdal 2.3.2

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Performance issue in coordinate transformations with Gdal 2.3.2

Stefan Moebius-2

Hi Even, Hi Thomas,

 

Thanks for your response and sorry for the late reply. School holidays and sickness generated quite some delays across my team.

 

Anyway, meanwhile we have improved our methodology for measuring the performance, by using JMH (https://openjdk.java.net/projects/code-tools/jmh/). What we found is that coordinate transformations have change their performance by roughly these margins:

 

GDAL 2.3.3 over GDAL 2.3.1, both with PROJ 4.8.0 (without ETMERC):

+50% WGS84 -> UTM projection and vice versa

+30% between different UTM projections

-10% UTM projection -> DHDN projection

 

GDAL 2.3.3 with PROJ 5.2.0 over GDAL 2.3.3 with PROJ 4.8.0 (with ETMERC):

+48% WGS84 -> UTM projection

+23% UTM projection -> WGS84

+60% between different UTM projections

+23% UTM projection -> DHDN projection

 

GDAL 2.4 adds another small margin across the board.

 

Overall, some of the transformations have indeed doubled their computation time.

 

Hope this is useful. If anyone is interested in the test sources, do let me know.

 

Regards,

Stefan

 

From: Thomas Knudsen <[hidden email]>
Sent: Tuesday, January 29, 2019 12:13
To: Even Rouault <[hidden email]>
Cc: Stefan Moebius <[hidden email]>; [hidden email]
Subject: Re: [gdal-dev] Perforce issue in coordinate transformations with Gdal 2.3.2

 

Prepare/finalize functions were added to pj_inv & pj_fwd  in PROJ PR #731 (https://github.com/OSGeo/proj.4/pull/731), in order to resolve ticket #700 (https://github.com/OSGeo/proj.4/issues/700).

These add some overhead as well but IIRC, more like +15% (much depending on the actual projection) than +100%.

 

Den man. 28. jan. 2019 kl. 17.38 skrev Even Rouault <[hidden email]>:

Stefan,

 

I bet you also upgraded your PROJ version in the process ? I can't think of a reason in GDAL itself for a performance change. But on the PROJ side, yes, there might be some explanation

The main one I can see is that in PROJ 4.9.3, the Extended Transverse Mercator is used by default for UTM, which has probably a higher computation time. If you define the GDAL configuration option / environmenet variable OSR_USE_ETMERC to NO, then the older Transverse Mercator method will be used.

PROJ 5.0 has also undergone major changes that might have increased a bit the computation time, but I wouldn't expect them to cause a 2x slowdown.

 

Even


--
Spatialys - Geospatial professional services
http://www.spatialys.com

 

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev


This email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

smime.p7s (3K) Download Attachment