[mapserver-dev] fastpath 4326->3857 reprojections

[Stephen Woodbridge]

Yeah, been updating stuff as I can, but older versions of proj4 don't 
have 3857, nor do the older versions of PostGIS, granted we can add 
records for that, but in some cases changes gets to be very complicated 
because it involves changes in whole applications starting at OpenLayers 
and working through all the backing stores and server side applications 
so everything is talking the EPSG codes.

Its happening but it is not going to happen overnight for most users 
with production environments. However, if they use this incentive to 
upgrade mapserver, then things like mapfiles get updated, and security 
fixes get deployed, etc. and the rest will follow.

Regards,
   -Steve W

On 2/11/2012 10:16 AM, thomas bonfort wrote:
> I'd be +0 on this: a speedup of this nature would be a nice incentive
> for users to update their mapfiles and services to use 3857 instead of
> the unofficial 900913 (the co-existence of these 2 identical codes has
> the consequence of forcing going through a useless reprojection when
> e.g. the layers are defined as 3857 but the request is in 900913).
> That said supporting both 900913 and 3857 in the fastpath would be
> trivial and wouldn't incur an additional cost performance wise.
>
> regards,
> thomas
>
> On Sat, Feb 11, 2012 at 16:02, Stephen Woodbridge
> <woodbri at swoodbridge.com>  wrote:
>> Wow! impressive results. While I know 3857 is the official code it would be
>> nice if the patch also recognized 900913 as an alias for 3857, because it
>> has been in common use for a few years.
>>
>> Thanks,
>>   -Steve W
>>
>>
>> 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
>>> _______________________________________________
>>> mapserver-dev mailing list
>>> mapserver-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
>>
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev