[mapserver-dev] fastpath 4326->3857 reprojections

[Jeff McKenna]

I think the fast patch should work both ways (4326 to 3857, and 3857 to 
4326).

I'm a strong +1 on using the approved 3857 EPSG code only, and forcing 
those to upgrade their legacy use of 900913 (yes, as painful as that can 
be).

-jeff


>>>
>>> On 2/11/2012 4:37 AM, thomas bonfort wrote:
>>>>
>>>> Hi all,
>>>>
>>>> During the codesprint I talked to Daniel about a possible speedup
>>>> patch we could use to bypass going through proj when performing the
>>>> common 4326 to 3857 (google mercator) reprojections. During my trip
>>>> back from the codesprint I implemented a quick patch that does this,
>>>> and I think that the benefits are sufficiently important under this
>>>> (rather common) test case to merit being pushed to trunk.
>>>>
>>>> test-case:
>>>> - using the mapserver-utils osm mapfile, we seed the first 6 zoom
>>>> levels of the google-mercator grid. Depending on the zoom level, this
>>>> mapfile has two (land and borders) or one (borders) layers that need
>>>> to go through reprojection. There are between 1 and 4 other layers
>>>> that are already in 3857 and therefore do not need reprojecting.
>>>> - the seeding is done with the mapcache seeding tool, which can be
>>>> configured to use multiple threads to do parallel rendering. The
>>>> seeding is done by directly using the libmapserver api (i.e. direct
>>>> calls to msDrawMap, not going through curl http getmap requests).
>>>> - bug 4041 (http://trac.osgeo.org/mapserver/ticket/4041) contains a
>>>> patch to avoid locking inside mapserver around proj calls, for trunk
>>>> versions of proj. In the following result spreadsheet "with/without
>>>> 480" refers to the fact that this patch is applied or not (480 stands
>>>> for version 4.8.0 of proj)
>>>>
>>>> without further ado, here's the resulting spreadsheet, which gives the
>>>> time in seconds needed to entirely seed the first 6 zoom levels:
>>>>
>>>>
>>>> https://docs.google.com/spreadsheet/pub?key=0AnCiCdIXpTHidHJ0YzVmSW54WncwZ2lGSS1wQ2xNZHc&output=html
>>>>
>>>>
>>>> tl;dr
>>>>
>>>> - if we factor out thread locking (which concerns the cgi/fastcgi
>>>> performance), the speedup is x 2.5
>>>> - in the multithreaded seeding case, the speedup is x 37
>>>>
>>>> --
>>>> thomas