[MapServer-dev] Custom Projections in MapServer 8 / Proj 6+

Even Rouault even.rouault at spatialys.com
Sat Jan 14 03:45:26 PST 2023


Seth,

> In Proj4 adding new projections was as simple as adding a new string to the epsg text tile in the PROJ_LIB directory. With Proj6+ the proj.db Sqlite database is used. I believe the text files are no longer used at all

+init=foo:bar should still try to use a "foo" text file. And if you have 
an "epsg" text file, it will have precedence over proj.db for 
+init=epsg:XXXX codes (although I don't recommend this, because proj.db 
will be completely ignored for any epsg entry, so you'd better make sure 
your text file is complete enough)

(although the GIS Internals proj7/share includes an other.extra file in the same format - is this also ignored?).

I presume +init=other.extra:XXXX should still work

>
> So to add a new projection would require adding a new record to proj.db.
> The docs at https://proj.org/apps/projinfo.html refer to a `--dump-db-structure` parameter:
>
>>     New in version 8.1.
>>
>>     Outputs the sequence of SQL statements to create a new empty valid auxiliary database.
>> 	This option can be specified as the only switch of the utility.
>> 	If also specifying a CRS object and the --output-id option, the
>> 	definition of the object as SQL statements will be appended.
> There is also a new environment variable (see Even's comment at [3]) - PROJ_AUX_DB that allows this to be read by Proj.
>
> - Is this the recommended approach for MapServer users? (Import any new projections into a new proj_extra.db and setting this as an environment variable).
The mechanism technically works but it has been reported in 
https://github.com/OSGeo/PROJ/issues/2904 that there are at least in 
some use cases with significant performance degradation. I'm not 
completely sure if it would affect Mapserver use cases though, and the 
degradation would only affect the setup of reprojection objects, so it 
should likely be OK for FastCGI scenarios where they are cached and thus 
an extra cost can be amortized.
> - What is the recommended approach for MapServer deployments with PROJ >=6 and <=9?
Not easy to answer this. To be honest nothing has beaten yet the 
simplicity of old PROJ.4 string. If you have not too complex 
requirements regarding datum shifts expressed by those and aren't 
mapping at a sub-metric level, they are probably good enough for most 
use cases. If you want to be able to express geodesy-grade datum 
transformations, you'd better setting up proper CRS and transformation 
records, either by patching proj.db or using an auxiliary database.
> - Is PROJ_AUX_DB a setting that can be added to the MapServer CONFIG file?
Probable not. I assume that currently, it should be set by the HTTP 
server itself, before it forks mapserver CGI. In a CONFIG block, this 
would only go through CPLSetConfigOption() but PROJ reads through 
getenv() or if it was set with proj_context_set_database_path(). I 
presume the msSetConfigOption() logic should have a special case similar 
to the PROJ_DATA one so that setting PROJ_AUX_DB calls 
OSRSetPROJAuxDbPaths() (GDAL >= 3.3)
> - Would it be worth adding  the PROJ and GDAL versions to the mapserver -v output as several of these options rely on newer versions of PROJ?

why not

Even

-- 

http://www.spatialys.com
My software is free, but my time generally not.



More information about the MapServer-dev mailing list