I was able to fix the crash by naming the .gsb files EXACTLY like Andy wrote below - my name before was chenys06a.gsb. After I created a symblink to CHENYX06a.gsb the crash was gone.
This looks really strange. Are thoses .gsb file names hard coded somewhere? Quite a mystery ... Andreas On 2016-10-28 16:45, Neumann, Andreas wrote: > Hi Andy, > > 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: > https://github.com/qgis/QGIS-Documentation/pull/1481 > > ------- > > 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! > > Andreas > > On 2016-10-24 11:09, Schmid Andreas wrote: > Hi, > > 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 > (https://github.com/qgis/QGIS/commit/70863ecaf0ccfcb538e3892af4b528304b21a0a2). > 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 > option: > InitialEnv > DEFAULT_DATUM_TRANSFORM=EPSG:21781/EPSG:2056/100001/-1;EPSG:2056/EPSG:21781/-1/100001 > > 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 > tbl_datum_transform. > > Regards, > Andy > > -----Ursprüngliche Nachricht----- > Von: Qgis-user [mailto:qgis-user-boun...@lists.osgeo.org] Im Auftrag von > Richard > Duivenvoorde > 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 > datum > conversions > > 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. > > _______________________________________________ > Qgis-user mailing list > Qgisfirstname.lastname@example.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-user > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user _______________________________________________ Qgis-user mailing list Qgisemail@example.com List info: http://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
_______________________________________________ Qgis-user mailing list Qgisfirstname.lastname@example.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user