Bug report #7941

IGNF:LAMBE -- not reprojecting

Added by Jeff Moyen over 11 years ago. Updated over 10 years ago.

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).

lambert_projection_problem.prj.qgs (1.94 KB) Benoit Laurent, 2013-07-21 11:30 PM

action.PNG (78.2 KB) Benoit Laurent, 2013-07-23 05:17 AM

exception.PNG (45.2 KB) Benoit Laurent, 2013-07-23 05:17 AM

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

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

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 :
  1. edit C:\\OSGeo4W64\\apps\\grass\\grass-6.4.3\\etc\\env.bat
  2. 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
  3. 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.

Also available in: Atom PDF