<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8">Depending on your use case, it might be worthwhile to convert the grid shift file in question into a key-value structure such as a hashmap (you can use a perfect hash function for this, since all the values are known ahead of time), and serialise that to disk. Your conversion routine then has two steps: convert using PROJ without the grid shift step to obtain the uncorrected new coordinates, then look up the shift values for those coordinates in the hash map, and perform the bilinear interpolation manually to obtain the corrected coordinates.<div><br></div><div>There are drawbacks: the serialised hashmap will be quite large on disk (less than 100 MB, I would imagine), and you’re adding complexity to your conversion pipeline, but it may be worth it for you if you have a need to convert coordinates at scale on a regular basis, such that a 30x slowdown is too large. I’ve found it to be a worthwhile approach for very fast conversion from WGS84 to OSGB36, using the OSTN15 transform: <a href="https://github.com/urschrei/lonlat_bng">https://github.com/urschrei/lonlat_bng</a>, but in retrospect it’s difficult to judge whether it was worthwhile from a cost / benefit perspective.<br><br><div dir="ltr">-- <div>steph</div></div><div dir="ltr"><br><blockquote type="cite">On 2 Jul 2021, at 16:13, Even Rouault <even.rouault@spatialys.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Kilian,</p>
<p>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.</p>
<p>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
<a class="moz-txt-link-freetext" href="https://github.com/OSGeo/PROJ-data/blob/master/fr_ign/fr_ign_ntf_r93.tif">https://github.com/OSGeo/PROJ-data/blob/master/fr_ign/fr_ign_ntf_r93.tif</a>
GeoTIFF grid (also available at
<a class="moz-txt-link-freetext" href="http://cdn.proj.org/fr_ign_ntf_r93.tif">http://cdn.proj.org/fr_ign_ntf_r93.tif</a>), 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)<br>
</p>
<p>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()</p>
<p>Even<br>
</p>
<div class="moz-cite-prefix">Le 02/07/2021 Ã 15:44, Kilian
Demeulemeester a écrit :<br>
</div>
<blockquote type="cite" cite="mid:21b0915a-3bd3-065d-ec93-c8246ffe4326@yellowscan-lidar.com">
Hi, <br>
<br>
I've added the support of grid shift in the software suite we are
developing here at YellowScan. <br>
<br>
Now that the grid shift files are found, the coordinates are
projected correctly and our customer is happy. <br>
<br>
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. <br>
<br>
The projection pipeline used is: <br>
<br>
+proj=pipeline
<p>+step +proj=push +v_3</p>
<p>+step +proj=cart +ellps=WGS84</p>
<p>+step +proj=helmert +x=168 +y=60 +z=-320</p>
<p>+step +inv +proj=cart +ellps=clrk80ign</p>
<p>+step +proj=pop +v_3</p>
<p>+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</p>
<p>+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</p>
<p>+step +proj=hgridshift +grids=ntf_r93.gsb</p>
<p>+step +proj=lcc +lat_0=46.5 +lon_0=3 +lat_1=49 +lat_2=44
+x_0=700000 +y_0=6600000 +ellps=GRS80</p>
<p><br>
</p>
<p>The grid shift file used is ntf_r93.gsb</p>
<p><br>
</p>
<p>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).</p>
<br>
Any help is appreciated! <br>
<br>
Cheers ! <br>
<br>
<div class="x-disclaimer-534644925">
<table width="450">
<tbody>
<tr>
<td colspan="2">
<p><strong>Kilian Demeulemeester<em></em></strong><br>
Software Project Lead - R&D</p>
</td>
</tr>
<tr>
<td>
<p><a href="https://yellowscan-lidar.com" moz-do-not-send="true"></a></p><div><a href="https://yellowscan-lidar.com" moz-do-not-send="true"><x-disclaimer-534644925-0.png></a></div><p></p>
</td>
<td>
<p>525 Avenue Saint Sauveur du Pin<br>
34980 Saint-Clément-De-Rivière - France<br>
Tel: +33 (0)4 11 93 14 06<br>
<a href="https://yellowscan-lidar.com" moz-do-not-send="true"><span>yellowscan-lidar.com</span></a></p>
</td>
</tr>
</tbody>
</table>
<table>
<tbody>
<tr>
<td><a title="Learn more and join us for a demo day!" href="https://www.yellowscan-lidar.com/events/category/demo-days/?utm_source=email_signature&utm_medium=email&utm_campaign=demodays_banner" moz-do-not-send="true"><img alt="" moz-do-not-send="true" width="443" height="80" data-unique-identifier=""></a></td>
</tr>
</tbody>
</table>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
PROJ mailing list
<a class="moz-txt-link-abbreviated" href="mailto:PROJ@lists.osgeo.org">PROJ@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/proj">https://lists.osgeo.org/mailman/listinfo/proj</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
<span>_______________________________________________</span><br><span>PROJ mailing list</span><br><span>PROJ@lists.osgeo.org</span><br><span>https://lists.osgeo.org/mailman/listinfo/proj</span><br></div></blockquote></div></div></body></html>