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

[Even Rouault]

On mercredi 2 octobre 2019 12:44:05 CEST Seth G wrote:
> 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.

That could. I always struggle with Appveyor/Windows, so I'd happily let that 
as an exercice for other contributors :-) (I don't anticipate any particular 
issue specific to Windows compilation)

> 
> - 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.

There might be an impact even if there is no reprojection, especially if 
working with EPSG codes, because you still have to instanciate a projection 
object, and whatever you use PROJ 4 or PROJ 6 API, with PROJ 6, resolving a 
EPSG code will go through the proj.db

I've just done a little experiment by modifying my bench to use EPSG:4326 
everywhere:
- for one iteration, with PROJ 4 API: 11 ms/iter. With PROJ 6 API: 10 ms/iter
- for 500 iterations, with PROJ 4 API: 0.8 ms/iter. PROJ 6 API: 0.9 ms/iter

I'm not sure why the PROJ 6 single iteration is a little faster than the PROJ 
4 one

Another data point is that if I bench against PROJ 5.1 (so using PROJ 4 API), 
I get 5 ms for the single iteration case (and 0.8 ms/iter for the 500 
iteration cases). So there's an additional cost using PROJ 6 in a single 
iteration case, whatever API you use. This is clearly related to querying the 
database and constructing a in-memory GeographicCRS PROJ object, whereas PROJ 
< 6 would just load a pre-baked PROJ string.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com