[gdal-dev] Performance issue in coordinate transformations with Gdal 2.3.2

Stefan Moebius Stefan.Moebius at amdocs.com
Fri Mar 22 02:10:34 PDT 2019

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


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


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





From: Thomas Knudsen <knudsen.thomas at gmail.com> 
Sent: Tuesday, January 29, 2019 12:13
To: Even Rouault <even.rouault at spatialys.com>
Cc: Stefan Moebius <Stefan.Moebius at amdocs.com>; gdal-dev at lists.osgeo.org
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
reserved=0> ), in order to resolve ticket #700
vB1E%3D&reserved=0> ).

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 <even.rouault at gmail.com
<mailto:even.rouault at gmail.com> >:



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

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.



Spatialys - Geospatial professional services


gdal-dev mailing list
gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190322/60b4c1ca/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2526 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190322/60b4c1ca/attachment.bin>
-------------- next part --------------
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 <https://www.amdocs.com/about/email-terms-of-service>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190322/60b4c1ca/attachment-0001.html>

More information about the gdal-dev mailing list