Bug report #18597
Layer reprojection from EPSG:3844 to EPSG:4326 has offset since QGIS 2.18.8
| 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:
History
#1
Updated by L Sz about 6 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 about 6 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.
#4
Updated by Andre Joost about 6 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 about 6 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 about 6 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 over 5 years 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 over 5 years 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 over 5 years ago
- Description updated (diff)
- Status changed from Feedback to Open
- Assignee deleted (
Jürgen Fischer)
#10
Updated by Jürgen Fischer over 5 years 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 over 5 years ago
- Status changed from Open to Closed