Bug report #18597

Layer reprojection from EPSG:3844 to EPSG:4326 has offset since QGIS 2.18.8

Added by L Sz almost 2 years ago. Updated about 1 year ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Projection Support
Affected QGIS version:2.18.8 Regression?:Yes
Operating System:Windows 64-bit and Ubuntu 64-bit Easy fix?:No
Pull Request or Patch supplied:No Resolution:up/downstream
Crashes QGIS or corrupts data:No Copied to github as #:26485

Description

Good reproject
QGIS-OSGeo4W-2.18.7 (and probably previous versions too)
EPSG:3844 - Pulkovo 1942(58) / Stereo70

+proj=sterea +lat_0=46 +lon_0=25 +k=0.99975 +x_0=500000 +y_0=500000 +ellps=krass +towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +units=m +no_defs

Reproject with offset
QGIS-OSGeo4W-2.18.8 (and probably every version since 2.18.8)

+proj=sterea +lat_0=46 +lon_0=25 +k=0.99975 +x_0=500000 +y_0=500000 +ellps=krass +towgs84=2.329,-147.042,-92.08,0.309,-0.325,-0.497,5.69 +units=m +no_defs

Reproject with offset
Ubuntu 17.10.1 - Qgis 3.0.1 Girona

+proj=sterea +lat_0=46 +lon_0=25 +k=0.99975 +x_0=500000 +y_0=500000 +ellps=krass +towgs84=2.329,-147.042,-92.08,0.309,-0.325,-0.497,5.69 +units=m +no_defs

Example:
Example offset

offset.JPG - Example offset (288 KB) L Sz, 2018-03-31 06:01 PM

3844_to_4326.zip (7.03 KB) L Sz, 2018-04-09 09:01 AM

History

#1 Updated by L Sz almost 2 years ago

The offset occurs in 2.18.8 even with custom CRS (+proj=sterea +lat_0=46 +lon_0=25 +k=0.99975 +x_0=500000 +y_0=500000 +ellps=krass +towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +units=m +no_defs).

#2 Updated by Andre Joost almost 2 years ago

According to http://epsg.io/3844-1645, the shift parameters of datum Pulkovo 1942(58) are different for Poland and Romania. Unfortunatley, EPSG:3844 (valid only in Romania) was bundled with the Poland values for GDAL 2.1.3 and earlier. The current version GDAL 2.2.3 takes the right dataset. Nothing to blaim QGIS for ...

I'm not sure how your data is collected and processed. KML files are always EPSG:4326, so maybe they are reprojected wrongly. Maybe you can upload an unprocessed sample data file.

#3 Updated by L Sz almost 2 years ago

Thank you for interest.

#4 Updated by Andre Joost almost 2 years ago

If you delete the .qpj files from your zip, create a custom CRS with the parameters from #1 and assign that to your 3844.shp, it aligns to Google background.
Now save that to a new file, choosing EPSG:3844, you have the right coordinates in Stereo70, still aligning to Google imagery. Same for reprojecting to EPSG:4326 as kml or else.

The shift parameters in older QGIS versions were wrong, and if you digitized with these wrong parameters from WGS84-based imagery like Google, you have to use the described workaround to work on with your data.

For the change in GDAL, see https://trac.osgeo.org/gdal/changeset/37081. It was implemented in GDAL 2.2.0, and depending on your Ubuntu repo you have it applied or not yet.

#5 Updated by L Sz almost 2 years ago

(give it a try, if you want:)
- Download the polyline shapefile of Romania’s national boundary (Frontieră România polilinie) from here:
http://www.geo-spatial.org/download/romania-seturi-vectoriale
or
the Romanian Natura 2000 boundaries (Rețeaua Natura 2000: [29.08.2017]) from the Environment Ministry’s website (polygon) from here:
http://www.mmediu.ro/articol/date-gis/434
(sorry, but these pages are not available in English)

- Save as WGS84 with Qgis 2.18.7 or older version
- Save as WGS84 with Qgis 2.18.8 or newer version
- See the difference / offset (aprox. 40 m)
- Observe that the first save (Qgis 2.18.7 or older version) is the correct one.

#6 Updated by L Sz almost 2 years ago

Someone sent me a set of parameters:
towgs84=2.3283,-147.0416,-92.0802,-0.30924979,0.32482188,0.49730012,5.68907711
I made a custom CRS with this, and it seems to work.

Looking up on the internet, I came across this page:
https://trac.osgeo.org/geotiff/ticket/52?cversion=0&cnum_hist=6

#7 Updated by Jürgen Fischer about 1 year ago

  • Status changed from Open to Feedback

Please test with QGIS 3.4 - QGIS 2.18 reached it's end of life.

#8 Updated by L Sz about 1 year ago

  • Assignee set to Jürgen Fischer

I tried this both in Qgis version 3.4.3 and 3.4.4:
I set the CRS of project and new layer to EPSG 3844.
Case 1: Open national boundary polyline or Natura 2000 polygon mentioned above with .prj:
Generated CRS - USER 1000XX Extent: Extent not known Proj4: +proj=sterea +lat_0=46 +lon_0=25 +k=0.99975 +x_0=500000 +y_0=500000 +ellps=krass +towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +units=m +no_defs
(this parameters are - I think - from EPSG 3844 definition in Qgis 2.18.7 and before)
Case 2: these layers without .prj or a newly created layer:
EPSG 3844.
Putting them together in EPSG 3844 (or transforming into EPSG 4326) between case 1 and 2 there is a 35-38 m offset (the first case is the correct one).

#9 Updated by Jürgen Fischer about 1 year ago

  • Description updated (diff)
  • Status changed from Feedback to Open
  • Assignee deleted (Jürgen Fischer)

#10 Updated by Jürgen Fischer about 1 year ago

  • Resolution set to up/downstream

The CRS database is updated from GDAL on install. The parameters changed there - QGIS just followed. GDAL currently has:

$ gdalsrsinfo -o proj4 EPSG:3844
+proj=sterea +lat_0=46 +lon_0=25 +k=0.99975 +x_0=500000 +y_0=500000 +ellps=krass +towgs84=2.329,-147.042,-92.08,0.309,-0.325,-0.497,5.69 +units=m +no_defs 

I guess an additional transformation should be added to datum_shift.csv (not sure how that currently is maintained in GDAL - but GDAL barn will change that).

#11 Updated by Giovanni Manghi about 1 year ago

  • Status changed from Open to Closed

Also available in: Atom PDF