[Qgis-user] QGIS server: configuration of grid shift files for datum conversions

Richard Duivenvoorde richard at duif.net
Mon Oct 24 01:01:26 PDT 2016


On 2016-10-24 06:23, Neumann, Andreas wrote:
> Hi,
> 
> I have to configure QGIS server to properly handle grid shift files.
> In Switzerland we need to offer "old" and "new" coordinates (different
> datums) at the same time with our services and the conversion needs to
> be done with grid shift files or tin based interpolation.
> 
> I know that I have to copy the CHENYX06a.gsb file to my proj lib, e.g.
> /usr/local/shar/proj  - but how can I make QGIS Server to actually use
> this file? I assume that I need to copy an additional config file or
> SRS/grid shift file combinations to QGIS server and/or specify an
> environment variable - right?
> 
> Are there any resources explaining how I can configure QGIS server to
> make use of these grid shift files?
> 
> Thank you for any pointers!

Hi Andreas,

funny, in NL we just had a discussion about how to handle different 
available datum transformation too last week...

we also recently got a grid shift file to better handle datum 
transformation and I found this post of Sourcepole:
http://blog.sourcepole.ch/2014/02/18/ntv2-transformations-with-qgis/
Which I think answers your question (at least for the desktop side)

But from a mini presentation from somebody from our National Cadastre, I 
actually draw the conclusion that the way QGIS represents CRS's is too 
narrow/not complete...

Please correct me if I'm wrong, but a lot of 'On The Fly'-reprojections 
actually need 2(!) proj configurations/steps:
- the projection parametes (mostly available in the epsg database)
- the datum transformation parameters (these is the 'towsg84...'-part, 
AND only needed when you do an actual datum transformation, PARTLY 
available in the epsg database)
The last part can either be a list of parameters (to calculate it) OR 
(as in your case and in the dutch preferred case) a grid shift file (as 
proj can only handle one of these).

SO: for example for certain crs's (in QGIS the dutch one is called 
epsg:28992) there is actually a SET of combinations available: the 
projection and 4 or 5 transformations 
(http://pix.toile-libre.org/upload/original/1477238061.png),

QGIS actually picks one (from qgis.db) of these and present them to the 
user as THE epsg:28992 crs, while in our case this is actually not the 
best fit, and in your case you actually want to pick two!

I understood that in ArcGIS, the user actually every time is presented 
with a 'pick the right datum transformation' dialog as soon as the data 
needs a datum transformatio. As a draw back: making it more difficult 
for new users to pick the right one, BUT on the positive side making it 
easier to pick the right projection/datumtransformation pair!

So what about using both worlds:
- in the qgis.db / crs table NOT use the projection-name as 
crs-identifier (so NOT epsg:28992), BUT the combination of projection 
AND datumtransformation, so in our case (28992_4833, 28992_15934, or 
epsg28992_epsg4833, epsg28992_qgis0001 to be able to handle 
projection/transformation combinations not available in the epsg db)
- and instead of current possibility to have a 'check'-box to have the 
'select datum transformation' popup we make this available in the 
'choose crs'-dialog with a button, and then 'remember' the last used 
crs's (in which a crs is NOT only the projection anymore but a 
projection/transformation combi)

IF QGIS starts using this combinations AND proj/gdal will ship all 
gridfiles towgs-paramters etc etc, this will become a better world :-)

Does this make sense? Do others get excited from this idea too?

Regards,

Richard Duivenvoorde

ps about providing the gridfiles, I urge our national Kadaster to make 
it available as treu open geodata, that is without a copyright 
disclaimer, so it can be picked up by Debian and other distro's.




More information about the Qgis-user mailing list