<div dir="ltr">Thanks for the response Even.<div><br></div><div>Switching to 4329 drops a few milliseconds, no major improvement.</div><div><br></div><div>If I still create the projection objects but don't actually project the point object then the execution time drops back to 0m0.180s or thereabouts. Creating the projection objects is just running msLoadProjectionString() under the hood. Must not be doing that much - no reprojector is being created.</div><div><br></div><div>$point->project() is running msProjectPoint() under the hood. I'm guessing the reprojector is being constructed every time that's called.</div><div><br></div><div>Note that I don't see a performance hit with 7.6 or 8.0 (main) with CGI when doing loads of reprojection.</div><div><br></div><div>So, following on your idea we'd need changes to the swig interface:</div><div><ol><li>reprojector.i - with a constructor to take in/out projection objects</li><li>overloaded project methods added to line.i, point.i, rect.i and shape.i</li></ol></div><div>I'll try that.</div><div><br></div><div>--Steve</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 8, 2022 at 11:09 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Steve,<br>
<br>
are you sure you don't still run into the projection initialization, or <br>
actually the cost to get the reprojector object from the (in, out) <br>
projection tuple from the cache maintained by createNormalizedPJ() ?<br>
<br>
If the following functions were mapped to SWIG<br>
<br>
   MS_DLL_EXPORT reprojectionObj* <br>
msProjectCreateReprojector(projectionObj* in, projectionObj* out);<br>
<br>
   MS_DLL_EXPORT int msProjectPointEx(reprojectionObj* reprojector, <br>
pointObj *point);<br>
<br>
that could be interesting to check if they speed up things.<br>
<br>
You might also try to check if using EPSG:4269 instead of EPSG:4326 <br>
wouldn't speed up things, to eliminate the datum change from the <br>
equation (if you have PROJ grids available, they might be used to do the <br>
NAD83 -> WGS84 shift)<br>
<br>
Even<br>
<br>
Le 08/06/2022 à 17:50, Steve Lime a écrit :<br>
> Hi all: I have a Perl script that runs against a shapefile to project <br>
> a geometry centroid from UTM to Lat/Lon. Code looks something like this:<br>
><br>
> my $proj_26915 = new mapscript::projectionObj('epsg:26915');<br>
> my $proj_4326 = new mapscript::projectionObj('epsg:4326');<br>
><br>
> while (my $shape = $layer->nextShape()) {<br>
>     my $point = $shape->getCentroid();<br>
>     $point->project($proj_26915, $proj_4326);<br>
>     # do something with $point<br>
> }<br>
><br>
> I get the following representative timings with ~250 polygon <br>
> geometries in the shapefile.<br>
><br>
>   MapServer 7.4 + Proj 6.2.1 = 0m0.180s<br>
>   MapServer 7.6 + Proj 6.2.1 = 0m7.000s<br>
>   MapServer 8.0 (main) + Proj 7.2.1 = 0m4.300s<br>
><br>
> Huge difference and things kinda become unusable. Things improve a bit <br>
> with newer versions but the performance hit is substantial. I <br>
> thought at first that it was the projection initialization that was <br>
> taking all the time but it's actually the <br>
> "$point->project($proj_26915, $proj_4326);" statement.<br>
><br>
> Perhaps I'm doing something wrong?<br>
><br>
> --Steve<br>
><br>
> _______________________________________________<br>
> MapServer-users mailing list<br>
> <a href="mailto:MapServer-users@lists.osgeo.org" target="_blank">MapServer-users@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/mapserver-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-users</a><br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
</blockquote></div>