Bug report #7941
IGNF:LAMBE -- not reprojecting
Status: | Closed | ||
---|---|---|---|
Priority: | Severe/Regression | ||
Assignee: | - | ||
Category: | Projection Support | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | Windows | Easy fix?: | No |
Pull Request or Patch supplied: | No | Resolution: | fixed/implemented |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 16809 |
Description
Hi,
I'm having problems with QGIS since more or less a month (early May). Before that date, I was using a version 1.8 and was happy with it. In Early May, for some reason QGIS stopped working (possibly because I installed something else and messed up with libs); I reinstalled QGIS as follows:
- Windows 7
- QGIS 1.8
The current version I'm describing the bug for is QGIS 1.8.0-Lisboa rev. ac2970b, GDAL 1.9.2, installed from Osgeo4w installer.
The problem arises specifically with layers whose CRS is IGNF:LAMBE and try to display it for instance in an EPSG:4326 project, on the fly projection enabled.
Upon loading one such layer (raster or vector), QGIS cannot reproject it on the fly and comes with an error message
Impossible de reprojeter l'emrpise de la couche Poursuivre la transformation de (-0.080374, 0.706336) (....) (0.155981, 0.902190) (0.199656, 0.899465) PROJ.4: +proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0 +k_0=0.99987742 +x_0=600000 +y_0=2200000 +a=6378249.2 +b=6356514.999978254 +nadgrids=ntf_r93.gsb,null +pm=2.337229167 +units=m +no_defs +to +proj=longlat +datum=WGS84 +no_defs Erreur: failed to load datum shift file
The error appears (1) if I did set the project properties to 4326, on the fly enabled, and try to load the layer; the moment I define the CRS. or (2) if, having loaded the layer in a "non-reprojected" project, I try to enable on the fly projection to 4326 (or, it seems, to about anything else, but I've not done systematic tests).
History
#1 Updated by Benoit Laurent about 11 years ago
The problem also occurs on version 1.9.0
#2 Updated by Giovanni Manghi about 11 years ago
- Category set to Projection Support
- Status changed from Open to Feedback
Can you attach sample data? Thanks.
#3 Updated by Benoit Laurent about 11 years ago
In a new project, if I just enable 'On the fly' CRS transformation and select RGF93/Lambert-93 for instance, QGis throws an exception. The problem also occurs with all Lambert CRS.
#4 Updated by Giovanni Manghi about 11 years ago
Benoit Laurent wrote:
In a new project, if I just enable 'On the fly' CRS transformation and select RGF93/Lambert-93 for instance, QGis throws an exception. The problem also occurs with all Lambert CRS.
I made a few tests with epsg 2154 (On Linux and Windows) and I cannot confirm. If you can attach the problematic project and data it would be better to allow troubleshoot the issue.
#5 Updated by Benoit Laurent about 11 years ago
- File lambert_projection_problem.prj.qgs added
Indeed, I could not reproduce the problem with RGF93/Lambert-93. It's weird. However, I could with :
- IGNF:LAMB1,
- IGNF:LAMB1C,
- IGNF:LABM2,
- IGNF:LAMB2C,
- IGNF:LAMB2E,
- IGNF:LAMB3,
- IGNF:LAMB3C,
- IGNF:LAMB4,
- IGNF:LAMB4C.
I joined my project.
#6 Updated by Giovanni Manghi about 11 years ago
Benoit Laurent wrote:
Indeed, I could not reproduce the problem with RGF93/Lambert-93. It's weird. However, I could with :
- IGNF:LAMB1,
- IGNF:LAMB1C,
- IGNF:LABM2,
- IGNF:LAMB2C,
- IGNF:LAMB2E,
- IGNF:LAMB3,
- IGNF:LAMB3C,
- IGNF:LAMB4,
- IGNF:LAMB4C.
I joined my project.
I cannot confirm with your project and any of the above crs. Please try on a clean installation or on another machine (or attach a project with data).
#7 Updated by Benoit Laurent about 11 years ago
- File action.PNG added
- File exception.PNG added
I installed QGis (last weekly release) on another computer (running on Windows XP) with the same result.
I just :
- launch QGis ;
- open the project properties ;
- enable the "on the fly transformation" checkbox ;
- choose one of the above mentionned crs.
QGis throws an exception.
I joined the dialog boxes as pictures.
#8 Updated by Giovanni Manghi about 11 years ago
- Status changed from Feedback to Open
- Operating System changed from QGIS 1.8.0 Windows to Windows
Now I see, but only on Windows.
Benoit Laurent wrote:
I installed QGis (last weekly release) on another computer (running on Windows XP) with the same result.
I just :
- launch QGis ;
- open the project properties ;
- enable the "on the fly transformation" checkbox ;
- choose one of the above mentionned crs.
QGis throws an exception.I joined the dialog boxes as pictures.
#9 Updated by Regis Haubourg about 11 years ago
confirmed here, first attempt to set IGNF:LAMB93 OK, second attempt with LAMB2C throws same exception..
we have a blocker for french users! Can anyone raise priority?
#10 Updated by Jürgen Fischer about 11 years ago
- Priority changed from Normal to Severe/Regression
#11 Updated by Regis Haubourg about 11 years ago
Hi, google indicates that the error seems to come from proj4 gdal. Anyone confirms?
#12 Updated by Regis Haubourg about 11 years ago
same bug occurs when trying to export to file and reproject from LAM93 to LAMB2C. So proj4 is the problem.
L'export du fichier vectoriel a échoué. Erreur : Impossible de transformer un point pendant le dessin de l'entité avec l'id '175707379'. L'écriture est stoppée. (Exception: Poursuivre la transformation de (-0.004213, 0.805607) PROJ.4: +proj=lcc +lat_1=44 +lat_2=49 +lat_0=46.5 +lon_0=3 +x_0=700000 +y_0=6600000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs +to +proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0 +k_0=0.99987742 +x_0=600000 +y_0=2200000 +a=6378249.2 +b=6356514.999978254 +nadgrids=ntf_r93.gsb,null +pm=2.337229167 +units=m +no_defs Erreur: failed to load datum shift file)
#13 Updated by Giovanni Manghi about 11 years ago
- Resolution set to up-/downstream
- Status changed from Open to Closed
So if the problem is upstream I will close this ticket, please reopen if necessary.
#14 Updated by Jürgen Fischer about 11 years ago
regis Haubourg wrote:
same bug occurs when trying to export to file and reproject from LAM93 to LAMB2C. So proj4 is the problem.
[...]
on OSGeo4W the file "ntf_r93.gsb" is in the "proj-datumgrid" and the "proj" package depends on it. So it should be there.
#15 Updated by Jürgen Fischer about 11 years ago
- Resolution deleted (
up-/downstream) - Status changed from Closed to Reopened
Does the PROJ_LIB
point to .../share/proj
? That can be checked by running import os
and os.getenv("PROJ_LIB")
in the python console - if that's ok, please also check if the ntf_r93.gsb
is in the directory PROJ_LIB
points to.
#16 Updated by Benoit Laurent about 11 years ago
In my case, PROJ_LIB does not point to .../share/proj but directly to .../proj which does not exist.
os.getenv("PROJ_LIB")
'C:\\\\Program Files\\\\QGIS Weekly2\\\\proj'
That may explain the problem...
#17 Updated by Jürgen Fischer about 11 years ago
Benoit Laurent wrote:
os.getenv("PROJ_LIB")
'C:\\\\Program Files\\\\QGIS Weekly2\\\\proj'That may explain the problem...
Yes. Does C:\\\\Program Files\\\\QGIS Weekly2\\\\etc\\ini\\proj.bat
exist?
#18 Updated by Benoit Laurent about 11 years ago
Yes. Its content is:SET PROJ_LIB=%OSGEO4W_ROOT%\\share\\proj
It seems ok, doesn't it ?
#19 Updated by Hien TRAN-QUANG about 11 years ago
Ok, found the problem :
Grass sets wrongly environment variable :
in OSGEO4W_ROOT\\apps\\grass\\grass-6.4.3\\etc\\env.bat
line 13 is
set PROJ_LIB=%OSGEO4W_ROOT%\\proj
It should read
set PROJ_LIB=%OSGEO4W_ROOT%\\share\\proj
(which was correctly set in etc\\ini\\proj.bat )
#20 Updated by Benoit Laurent about 11 years ago
Does executing the env.bat file after the correction you suggest solve temporarily the problem ? Is it more complicated than that ?
#21 Updated by Jürgen Fischer about 11 years ago
Benoit Laurent wrote:
Does executing the env.bat file after the correction you suggest solve temporarily the problem ? Is it more complicated than that ?
env.bat
is automatically executed on start. So just changing it should do the trick.
#22 Updated by Hien TRAN-QUANG about 11 years ago
Grass' env.bat is called automaticaly after setting other setenv (python, gdal, and so on) and that typo overwrote the correct one.
That's not a temporary solve but a definite one.
#23 Updated by Jürgen Fischer about 11 years ago
- Resolution set to up-/downstream
Hien TRAN-QUANG wrote:
Ok, found the problem :
Grass sets wrongly environment variable :
in OSGEO4W_ROOT\\apps\\grass\\grass-6.4.3\\etc\\env.bat
good catch - filed a OSGeo4W #369
#24 Updated by Giovanni Manghi about 11 years ago
so I guess we can re-close this one?
#25 Updated by Benoit Laurent about 11 years ago
env.bat is automatically executed on start
It's time for the stupid question: when you write "on start", you mean when we launch qgis ? I made the correction, I launch QGis and the PROJ_LIB variable is still incorrect. I must miss something...
#26 Updated by Hien TRAN-QUANG about 11 years ago
Launching QGIS is in fact calling qgis.bat (or qgis-dev.bat) which calls o4w.bat then grass\\etc\\env.bat.
o4w.bat sets some environment variables (PYTHON_HOME for example) by calling \\etc\\ini\\*.bat That's where a first PROJ_LIB is defined.
But then grass's own setenv file (apps\\grass\\grass-xxxx\\etc\\env.bat) overwrites that definition.
#27 Updated by Benoit Laurent about 11 years ago
Launching QGIS is in fact calling qgis.bat (or qgis-dev.bat) which calls o4w.bat then grass\\etc\\env.bat.
o4w.bat sets some environment variables (PYTHON_HOME for example) by calling \\etc\\ini\\*.bat That's where a first PROJ_LIB is defined.
But then grass's own setenv file (apps\\grass\\grass-xxxx\\etc\\env.bat) overwrites that definition.
Ok, I better understand the process now. I eventually solved my other problem. Your correction works perfectly well. Thank you very much !
#28 Updated by Giovanni Manghi about 11 years ago
- Status changed from Reopened to Closed
So if I'm not wrong when can close this again... reopen if otherwise.
#29 Updated by Jeff Moyen almost 11 years ago
- Status changed from Closed to Reopened
Hi there,
it's back I'm afraid...
1. Install QGIS 2.0.1 / 64b (win 7)
2. load a WGS84 layer (in my case, a postGIS table with EPSG:4326)
3. activate on the fly reprojection, try to switch SCR to LAMBE
4. Watch the error message :-/
I did check OSGEO4W_ROOT\\apps\\grass\\grass-6.4.3\\etc\\env.bat (using the windows stand-alone installer, it happens to be C:\\PROGRA~1\\QGISDU~1, and the option window does say so); it does, correctly, read set PROJ_LIB=%OSGEO4W_ROOT%\\share\\proj.
Within Qgis option wondows, PROJ_LIB = C:\\PROGRA~1\\QGISDU~1\\share\\proj
So I'm afraid, the issue is back...
Best,
JF
#30 Updated by Cédric Duprez almost 11 years ago
Hi,
I have the same problem, which only happens with 64bit version.I could solve it doing this :
- edit C:\\OSGeo4W64\\apps\\grass\\grass-6.4.3\\etc\\env.bat
- change the 2 following lines :
set GDAL_DATA=%OSGEO4W_ROOT%\\share\\gdal
set PROJ_LIB=%OSGEO4W_ROOT%\\share\\proj
like this :
set GDAL_DATA="%OSGEO4W_ROOT%\\share\\gdal"
set PROJ_LIB="%OSGEO4W_ROOT%\\share\\proj"
(just adding the paths between double quotes - launch QGis again and it should be OK !
It works now for vector layers, but I still have the problem with raster layers.
Regards,
Cedric
#31 Updated by Jeff Moyen almost 11 years ago
Hello Cédric,
sorry to report that your solution does not work for me...
In a standalone install (not OSgeo4W), the file is of course at
C:\\Program Files\\QGIS Dufour\\apps\\grass\\grass-6.4.3\\etc
The double-quoting does not do the trick for me...
#32 Updated by Giovanni Manghi over 10 years ago
- Target version set to Version 2.2
- Resolution deleted (
up-/downstream)
As far I can see this is still an issue at least on osgeo4w 64bit
#33 Updated by Jürgen Fischer over 10 years ago
- Status changed from Reopened to Closed
- Resolution set to fixed/implemented
Giovanni Manghi wrote:
As far I can see this is still an issue at least on osgeo4w 64bit
Fixed in OSGeo4W.