[PROJ] Question about performances of proj_trans or proj_trans_generic when using a grid shift file

[Even Rouault]

Kilian,

looking at the NTv2 file reader, I see it will do a seek + read for each 
points to transform (actually 4 seek + read, given the bilinear 
interpolation). I suspect that might be costly.

The GTiff grid file reader keeps in memory the last used strip or tile, 
so if transformating locations that are sufficiently close from each 
other, the amont of file read is reduced. You could try to use the 
https://github.com/OSGeo/PROJ-data/blob/master/fr_ign/fr_ign_ntf_r93.tif 
GeoTIFF grid (also available at http://cdn.proj.org/fr_ign_ntf_r93.tif), 
which is a conversion from the NTv2 ntf_r93.gsb (and in that instance, 
it is a single block grid, so it will be just read once)

And your analysis is write: proj_trans_generic() will not give you 
speed-up (at least with current implementation) compared to repeated 
calls to proj_trans()

Even

Le 02/07/2021 à 15:44, Kilian Demeulemeester a écrit :
> Hi,
>
> I've added the support of grid shift in the software suite we are 
> developing here at YellowScan.
>
> Now that the grid shift files are found, the coordinates are projected 
> correctly and our customer is happy.
>
> However, the projection time completly exploded: for instance, on our 
> customer dataset, our LAS creation algorithm exports our data in 
> approx 5s without using a grid shift, and it now takes up to 2min20s 
> when using it.
>
> The projection pipeline used is:
>
> +proj=pipeline
>
> +step +proj=push +v_3
>
> +step +proj=cart +ellps=WGS84
>
> +step +proj=helmert +x=168 +y=60 +z=-320
>
> +step +inv +proj=cart +ellps=clrk80ign
>
> +step +proj=pop +v_3
>
> +step +proj=lcc +lat_1=44.1 +lat_0=44.1 +lon_0=0 +k_0=0.999877499 
> +x_0=600000 +y_0=3200000 +ellps=clrk80ign +pm=paris
>
> +step +inv +proj=lcc +lat_1=44.1 +lat_0=44.1 +lon_0=0 +k_0=0.999877499 
> +x_0=600000 +y_0=3200000 +ellps=clrk80ign +pm=paris
>
> +step +proj=hgridshift +grids=ntf_r93.gsb
>
> +step +proj=lcc +lat_0=46.5 +lon_0=3 +lat_1=49 +lat_2=44 +x_0=700000 
> +y_0=6600000 +ellps=GRS80
>
>
> The grid shift file used is ntf_r93.gsb
>
>
> Is this time normal? Is there a way to speed things up? I've tried to 
> use proj_trans_generic with no success, and exploring the source code 
> on github, I realized that it is using a for-loop approach, using 
> proj_trans (so no optimization to expect - but I might be wrong).
>
>
> Any help is appreciated!
>
> Cheers !
>
> *Kilian Demeulemeester//*
> Software Project Lead - R&D
>
> logo_Yellowscan <https://yellowscan-lidar.com>
>
> 	
>
> 525 Avenue Saint Sauveur du Pin
> 34980 Saint-Clément-De-Rivière - France
> Tel: +33 (0)4 11 93 14 06
> yellowscan-lidar.com <https://yellowscan-lidar.com>
>
> <https://www.yellowscan-lidar.com/events/category/demo-days/?utm_source=email_signature&utm_medium=email&utm_campaign=demodays_banner> 
>
>
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

-- 
http://www.spatialys.com
My software is free, but my time generally not.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210702/17ac978e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x-disclaimer-534644925-0.png
Type: image/png
Size: 1125 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210702/17ac978e/attachment.png>