[mapserver-dev] [mapserver-users] MapScript Projection Performance

[Steve Lime]

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 at 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 at 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 at lists.osgeo.org
>> > https://lists.osgeo.org/mailman/listinfo/mapserver-users
>>
>> --
>> 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/mapserver-dev/attachments/20220609/1047cd54/attachment.htm>