[PROJ] Performance of proj_create_crs_to_crs()

Even Rouault even.rouault at spatialys.com
Sun Feb 17 10:46:18 PST 2019


Paul,

This is a very interesting use case, and one that has probably the worse 
runtime.

On my system, the following runs in 16.9 s, so 170 ms per instanciation

        for(int i = 0; i < 100; i++)
        {
            PJ *pj = proj_create_crs_to_crs(NULL, "EPSG:3005", "EPSG:4267", 
NULL);
            proj_destroy(pj);
        }

so not as dramatic as 400 ms.

The reason is that the NAD27 <-> NAD83 conversion has several dozains of 
potential paths (one per US state), and PROJ explore them. But, after 
analysis, the main reason for the slowness was that it also tried by default 
to find an intermediate CRS to explore better alternate transformation paths, 
and WGS84 was a very prolific one in that case. But actually going through 
WGS84 doesn't really give better pipelines at the end.

I've just issued PR https://github.com/OSGeo/proj.4/pull/1276 which disables 
by default research of intermediate CRS when there is at least a direct 
transformation. This should be good enough for most use cases. With this 
change, in your use case, the above loop runs in 1.56 s, so 16 ms per 
instanciation.

Even

> So, having gotten all the axis swapping tap dancing working, I went to
> run some of my favourite transforms around BC, finishing up with one
> of my favourites...
> 
>  st_transform('SRID=3005;POINT(1000000 0)',4267)
> 
> This takes a point from a NAD83 projected system (EPSG:3005) to a
> NAD27 geodetic system (EPSG:4267).
> 
> Here's the crazy part: this transformation takes 400ms, and the time
> is all spend in in proj, getting the PJ.
> 
> I ran 20-30 of them in a row and captured the workload in Instruments
> in case these function calls ring any bells WRT overhead, screenshot
> attached.
> 
> Fortunately for bulk conversion PostGIS already caches the projection
> object, in fact most of my work this week was in renovating that part
> of the code, but older versions of Proj are much much faster in
> resolving projections from projection strings.
> 
> Thoughts?
> 
> P.


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


More information about the PROJ mailing list