Thank for these very precise instructions.
I was able to do the same on CentOS 7 with only very minor differences
(probably because I self-compile QGIS server).
Is the id 100001 for the swiss datum transformation stable?
I think this information should be added to the QGIS user manual, in the
server section. I created a pull request:
fyi: i get a server crash when I use a request in EPSG:2056, project
done in EPSG:21781 - still investigating what the reason is ...
Thanks a lot - very useful information!
On 2016-10-24 11:09, Schmid Andreas wrote:
> At Kanton Solothurn we had the same requirement. And we did not want to
> fiddle with the original proj.4 definition files. So we paid Sourcepole for
> solving this directly in QGIS Server
> This is how it works under Ubuntu:
> * Place those CHENYX06a.gsb and CHENYX06_etrs.gsb in /usr/share/proj
> (probably in our case only CHENYX06a.gsb is actually needed)
> * If QGIS Server was installed before placing the .gsb files, run
> /usr/lib/qgis/crssync (or run it anyway)
> * In /etc/apache2/mods-enabled/fcgid.conf place the following additional
> The meaning of this option is: when your .qgs is in EPSG:21781 and the WMS
> request is in EPSG:2056, then use datum transformation 100001; when your .qgs
> is in EPSG:2056 and the WMS request is in EPSG:21781, then use datum
> transformation 100001 as well, but use it the other way round.
> The datum transformation code 100001 can be looked up in
> /usr/share/qgis/resources/srs.db. Look at attribute coord_op_code of table
> -----Ursprüngliche Nachricht-----
> Von: Qgis-user [mailto:qgis-user-boun...@lists.osgeo.org] Im Auftrag von
> Gesendet: Montag, 24. Oktober 2016 10:01
> An: Neumann, Andreas
> Cc: QGIS User List
> Betreff: Re: [Qgis-user] QGIS server: configuration of grid shift files for
> 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:
> 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
> 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?
> 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.
> Qgis-user mailing list
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
Qgis-user mailing list
List info: http://lists.osgeo.org/mailman/listinfo/qgis-user