Bug report #5142

reprojection with towg84 parameters is broken in qgis-master

Added by Giovanni Manghi over 7 years ago. Updated almost 7 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Projection Support
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:worksforme
Crashes QGIS or corrupts data:No Copied to github as #:14899

Description

While it works fine in qgis 1.7.x, it seems that in master towg84 parameters are not taken into account anymore.

I will check also if this affects ntv2 grids.

jurgen.tar.gz (7.67 KB) Giovanni Manghi, 2012-03-14 06:40 AM

History

#1 Updated by Jürgen Fischer over 7 years ago

  • Priority changed from High to Normal

a bit vague. Did you check that the source and destination CRSes are picked up correctly?

#2 Updated by Giovanni Manghi over 7 years ago

Jürgen Fischer wrote:

a bit vague. Did you check that the source and destination CRSes are picked up correctly?

Hi Jurgen,

I can provide you with a small project/sample data, but the issue have been described well here

http://lists.osgeo.org/pipermail/qgis-developer/2012-March/018685.html

qgis-master seems to ignore the towgs parameters of the CRS in the internal database, but it works fine with custom CRSs.

Let me know.

#3 Updated by Giovanni Manghi over 7 years ago

see also #5143

#4 Updated by Jürgen Fischer over 7 years ago

Giovanni Manghi wrote:

Jürgen Fischer wrote:

a bit vague. Did you check that the source and destination CRSes are picked up correctly?

qgis-master seems to ignore the towgs parameters of the CRS in the internal database, but it works fine with custom CRSs.

Does that mean you checked if the CRS is found correctly in the database and the PROJ.4 string is what it should be (ie. including the +towgs84)? I suspect that the CRS was not found correctly and a similar CRS - just without the towgs84 parameter - was found.
Which would make this a duplicate of #5066 and possibly #4977.

#5 Updated by Giovanni Manghi over 7 years ago

Hi Jurgen

Does that mean you checked if the CRS is found correctly in the database and the PROJ.4 string is what it should be (ie. including the +towgs84)?

yes

I suspect that the CRS was not found correctly and a similar CRS - just without the towgs84 parameter - was found.

it is not the case.

But the situation is a bit more complex.

I updated to master both on Windows and Linux, and tested a small simple project that I have attached to this ticket.

The project is made of two vectors (one in epsg 3763, the other in epsg 27493) and defined in epsg 3763 with OTFR on. Without towgs84 parameters the same vertex of the two vectors are more or less 70/80 meters away (on the horizontal plane) from each other. When towgs84 parameters are used this difference drops to more or less 1 meter.

At this moment I see that when loading the project under Windows it works all as expected, under Linux does not -> the CRSs are correctly recognised but towg84 parameters seems to be not considered.

I noticed also another thing (probably not related to the above) that for a while made me think that also under Windows it was not working:

  • open a new project
  • add layers
  • enter project properties -> CRS tab
  • select the CRS from the "recently used CRS" and then check the OTFR checkbox
  • what happens is that when checking the OTFR checkbox a different CRS is selected in the "CRS of the world" window (in my case it picks some CRS from the "user defined" list). If a user does not give attention gets a project with a projection different from the one he choose.

Interesting enough, this does not happen anymore if the "project properties" dialog is open again (but only if the OTFR checkbox is active).

#6 Updated by Etienne Tourigny over 7 years ago

adding a note that Jurgen added a fix for this in c065736b71f856c22814d2f29f248b88e442ae6e

Full fix could be setting GDAL_FIX_ESRI_WKT=GEOGCS as this would add the EPSG authority node - although this is still not well tested.

Perhaps a config option would be in order?

#7 Updated by Giovanni Manghi over 7 years ago

Etienne Tourigny wrote:

adding a note that Jurgen added a fix for this in c065736b71f856c22814d2f29f248b88e442ae6e

for me still does not work on Linux/master but it works on Windows/master.

#8 Updated by Giovanni Manghi over 7 years ago

Jürgen Fischer wrote:

a bit vague. Did you check that the source and destination CRSes are picked up correctly?

Hi Jurgen,

until now I did tested master from the nightly build repo (on Ubuntu) and the issue is still there. Today I had to compile (in this case against gdal 1.9) and the issue is gone. Don't know if this can help, maybe is not a qgis issue after all. Cheers.

#9 Updated by Ivan Mincik about 7 years ago

I tested 'towgs' parameters problem on current Debian Wheezy (GDAL 1.9) an QGIS 1.8. 'towgs' parameters where not taken to account for CRSs from QGIS database, but they are correctly recognized for 'custom CRSs'.

#10 Updated by Giovanni Manghi about 7 years ago

Ivan Mincik wrote:

I tested 'towgs' parameters problem on current Debian Wheezy (GDAL 1.9) an QGIS 1.8. 'towgs' parameters where not taken to account for CRSs from QGIS database, but they are correctly recognized for 'custom CRSs'.

it works fine here under Ubuntu with qgis 1.8 compiled against gdal 1.9.... I was thinking to close this ticket.

#11 Updated by Paolo Cavallini about 7 years ago

  • Target version set to Version 2.0.0

#12 Updated by Giovanni Manghi almost 7 years ago

  • Resolution set to worksforme
  • Status changed from Open to Closed

seems to work fine now on master.

Also available in: Atom PDF