[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mapserver-dev
Subject:    Re: [mapserver-dev] [mapserver-users] MapScript Projection Performance
From:       Steve Lime <sdlime () gmail ! com>
Date:       2022-06-09 14:39:10
Message-ID: CAMrKZ9_r=hveHavkr5Sojtf2=ex8fTKuuTeSB=1UqQM-VoPRyg () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


The changes to MapScript help dramatically - at least using main. I end up
with code like:

my $proj_26915 = new mapscript::projectionObj('epsg:26915');
my $proj_4326 = new mapscript::projectionObj('epsg:4326');
my $reprojector =  new mapscript::reprojectionObj( $proj_26915,
$proj_4329);

while (my $shape = $layer->nextShape()) {
    my $point = $shape->getCentroid();
    $point->project($reprojector);
    # do something with $point
}

Execution time drops from ~4.3 sec to ~0.2 sec. Only change to the
mapproject.* source was moving the structure definition for a
reprojectionObj into the header file so Swig can get at it. I'll prepare a
pull request...

--Steve

On Wed, Jun 8, 2022 at 2:40 PM Steve Lime <sdlime@gmail.com> wrote:

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

[Attachment #5 (text/html)]

<div dir="ltr">The changes to MapScript help dramatically - at least using main. I \
end up with code like:<div><br></div><div><div>my $proj_26915 = new \
mapscript::projectionObj(&#39;epsg:26915&#39;);<br>my $proj_4326 = new \
mapscript::projectionObj(&#39;epsg:4326&#39;);</div><div>my $reprojector =  

new mapscript::reprojectionObj(

$proj_26915,  

$proj_4329);<br><div><br></div><div>while (my $shape = $layer-&gt;nextShape()) \
{<br></div></div><div>       my $point = $shape-&gt;getCentroid();</div><div>       \
$point-&gt;project($reprojector);</div><div>      # do something with \
$point</div><div>}</div><div><br></div></div><div>Execution time drops from ~4.3 sec \
to ~0.2 sec. Only change to the mapproject.* source was moving the structure \
definition for a reprojectionObj into the header file so Swig can get at it. I&#39;ll \
prepare a pull request...</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 2:40 PM \
Steve Lime &lt;<a href="mailto:sdlime@gmail.com">sdlime@gmail.com</a>&gt; \
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"><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&#39;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-&gt;project() is running  \
msProjectPoint() under the hood. I&#39;m guessing the reprojector is being \
constructed every time that&#39;s called.</div><div><br></div><div>Note that I \
don&#39;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&#39;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&#39;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 &lt;<a \
href="mailto:even.rouault@spatialys.com" \
target="_blank">even.rouault@spatialys.com</a>&gt; 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&#39;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&#39;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 -&gt; WGS84 shift)<br>
<br>
Even<br>
<br>
Le 08/06/2022 à 17:50, Steve Lime a écrit  :<br>
&gt; Hi all: I have a Perl script that runs against a shapefile to project <br>
&gt; a geometry centroid from UTM to Lat/Lon. Code looks something like this:<br>
&gt;<br>
&gt; my $proj_26915 = new mapscript::projectionObj(&#39;epsg:26915&#39;);<br>
&gt; my $proj_4326 = new mapscript::projectionObj(&#39;epsg:4326&#39;);<br>
&gt;<br>
&gt; while (my $shape = $layer-&gt;nextShape()) {<br>
&gt;        my $point = $shape-&gt;getCentroid();<br>
&gt;        $point-&gt;project($proj_26915, $proj_4326);<br>
&gt;       # do something with $point<br>
&gt; }<br>
&gt;<br>
&gt; I get the following representative timings with ~250 polygon <br>
&gt; geometries in the shapefile.<br>
&gt;<br>
&gt;    MapServer 7.4  + Proj 6.2.1 =  0m0.180s<br>
&gt;    MapServer 7.6  + Proj 6.2.1 =  0m7.000s<br>
&gt;    MapServer 8.0 (main) + Proj 7.2.1 =  0m4.300s<br>
&gt;<br>
&gt; Huge difference and things kinda become unusable. Things improve a bit <br>
&gt; with newer versions but the performance hit is substantial. I <br>
&gt; thought  at first that it was the projection initialization that was <br>
&gt; taking all the time but it&#39;s actually the <br>
&gt; &quot;$point-&gt;project($proj_26915, $proj_4326);&quot; statement.<br>
&gt;<br>
&gt; Perhaps I&#39;m doing  something wrong?<br>
&gt;<br>
&gt; --Steve<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; MapServer-users mailing list<br>
&gt; <a href="mailto:MapServer-users@lists.osgeo.org" \
target="_blank">MapServer-users@lists.osgeo.org</a><br> &gt; <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>
</blockquote></div>



_______________________________________________
MapServer-dev mailing list
MapServer-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/mapserver-dev


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic