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.tho...@gmail.com> Sent: Tuesday, January 29, 2019 12:13 To: Even Rouault <even.roua...@spatialys.com> Cc: Stefan Moebius <stefan.moeb...@amdocs.com>; gdal-dev@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.roua...@gmail.com <mailto:even.roua...@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@lists.osgeo.org <mailto:gdal-dev@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>
smime.p7s
Description: S/MIME cryptographic signature
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>
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
