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

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/>
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 <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
(https://github.com/OSGeo/proj.4/pull/731
<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
om%2FOSGeo%2Fproj.4%2Fpull%2F731&data=02%7C01%7CStefan.Moebius%40amdocs.com%
7C1af750be00dc439e8af008d685dade61%7Cc8eca3ca127646d59d9da0f2a028920f%7C0%7C
0%7C636843572476979244&sdata=SFr4nL70uT6NxoNcMnIYuxCxfhVmt4airGGxvPAhY9g%3D&
reserved=0> ), in order to resolve ticket #700
(https://github.com/OSGeo/proj.4/issues/700
<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
om%2FOSGeo%2Fproj.4%2Fissues%2F700&data=02%7C01%7CStefan.Moebius%40amdocs.co
m%7C1af750be00dc439e8af008d685dade61%7Cc8eca3ca127646d59d9da0f2a028920f%7C0%
7C0%7C636843572476979244&sdata=Wl1zUW%2BpkP%2Bu6phlj7OY%2B9oJtmMYUTM4Xa5pazH
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> >:

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
<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.spati
alys.com&data=02%7C01%7CStefan.Moebius%40amdocs.com%7C1af750be00dc439e8af008
d685dade61%7Cc8eca3ca127646d59d9da0f2a028920f%7C0%7C0%7C636843572476979244&s
data=a6NUnvhbQs8olqMY9%2B6zEr959T4KT1Iq2q0z9lUX18w%3D&reserved=0> 

_______________________________________________
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
<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.os
geo.org%2Fmailman%2Flistinfo%2Fgdal-dev&data=02%7C01%7CStefan.Moebius%40amdo
cs.com%7C1af750be00dc439e8af008d685dade61%7Cc8eca3ca127646d59d9da0f2a028920f
%7C0%7C0%7C636843572476979244&sdata=UjdRV5U5KE7Ao9%2Bfx0KlpzZIgzTN%2FCIoCg8t
WRtjXNg%3D&reserved=0> 

-------------- 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>