QGIS » QGIS Application

The problem also occurs on version 1.9.0

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.

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.

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

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?

Hi, google indicates that the error seems to come from proj4 gdal. Anyone confirms?

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)

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.

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

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?

Yes. Its content is:
SET PROJ_LIB=%OSGEO4W_ROOT%\\share\\proj

It seems ok, doesn't it ?

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 )

Does executing the env.bat file after the correction you suggest solve temporarily the problem ? Is it more complicated than that ?

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.

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.

so I guess we can re-close this one?

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

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.

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 !

Hi,

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

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