reprojection with towg84 parameters is broken in qgis-master

[qgib]

Author Name: Giovanni Manghi (@gioman)
Original Redmine Issue: 5142
Affected QGIS version: master
Redmine category:projection_support

---

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 (Giovanni Manghi)

[qgib]

Author Name: Jürgen Fischer (@jef-n)

---

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

---

• priority_id was changed from High to Normal

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

see also #14900

[qgib]

Author Name: Jürgen Fischer (@jef-n)

---

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 #14833 and possibly #14764.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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

---

• 4323 was configured as jurgen.tar.gz

---

• jurgen.tar.gz (Giovanni Manghi)

[qgib]

Author Name: Etienne Tourigny (@etiennesky)

---

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

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?

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

Etienne Tourigny wrote:

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

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

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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.

[qgib]

Author Name: Ivan Mincik (Ivan Mincik)

---

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

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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.

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

• fixed_version_id was configured as Version 2.0.0

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

seems to work fine now on master.

---

• resolution was changed from to worksforme
• status_id was changed from Open to Closed