[mapserver-dev] RFC 126: Port to PROJ 6 API

[Seth G]

Hi Even,

Great news getting PROJ6 integrated. 

A couple of questions. 

- Should Appveyor be updated to also test on Windows? I believe the GISInternals SDK has a bin/proj6 folder already. 

- With regards to start up performance/CGI I presume there is no impact if all source data is in the same projection as the request e.g. all data in the database is EPSG:3857 and Web Mercator requests are made. It might be a case of making sure users are aware of the impact of having to reproject. 

I hope at some point to add a few benchmark tests to the Python MapScript test suite - your proj test is a nice example. There is a plugin https://pypi.org/project/pytest-benchmark/ that could be useful.  


Seth

--
web:http://geographika.co.uk
twitter: @geographika

On Wed, Oct 2, 2019, at 12:09 PM, Even Rouault wrote:
> Hi Daniel,
> 
> > 
> > The significant performance hit caught my attention for the CGI case
> > which is a more common use case than the RFC seems to suggest.
> 
> I would strongly suggest using FastCGI then. By using pure CGI, you'll 
> definitely have to pay for the price of starting a new process, which is non 
> neglectable.
> On my machine, "time mapserv >/dev/null" is 177 ms in the best case... I'd say 
> that before trying to kill an extra 10ms, going after those 177ms should be 
> the priority.
> 
> > Is there
> > really not much that can be done about that?  Is it really just the
> > projection setup that is slower or are the coordinate conversions also
> > slower? 
> 
> From the reports of PROJ users (see https://github.com/OSGeo/PROJ/issues/1367 
> ), I think that projection setup is the main factor (and in my little bench, 
> there are very few points to transform, so a potential extra cost for each 
> coordinate conversion would't show up)
> 
> > Could we serialize the projection context pool for any given
> > mapfile to some kind of cache file in /tmp/ for instance and start from
> > the cached version at loadMap() time?  Could we get some gains this way
> > by not having to recompute all the projection transformations all the time?
> 
> I don't think that can be done on Mapserver side, at least not easily. For 
> example proj_create_crs_to_crs() can create an object that is a collection of 
> several potential coordinate transformations (depending on the area of use), 
> and proj_trans() will select the one that is appropriate. This is opaque to 
> the user.
> You could access to those different candidates by using the lower level API, 
> proj_create_operations(), and then you can access the PROJ pipeline string and 
> serialize it, but then you have to implement the logic to select the one that 
> is appropriate given your input coordinate.
> Your suggestion might work, but that's a non trivial effort and code 
> complication (handling the cache file could be tricky as well, to avoid 2 
> concurrent processes overwriting it at the same time, etc).
> Wondering if that might not be done by PROJ itself (but not so obvious, since 
> there is also a price to create a PROJ CRS object from a EPSG code, which 
> requires lookups in the database)
> 
> I'd say that considering such optimizations would be for a phase 2, and the 
> ratio effort/benefit is quite uncertain.
> 
> Even
> 
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-dev