Bug report #21477

Shift layer from ArcGIS, SRS 5514

Added by Vladimír Hans about 1 year ago. Updated about 1 year ago.

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

Description

If I create layer in ArcGIS in SRS 5514 and I load this in QGIS, there is shift about 9 m. SRS of project in QGIS is set 5514. If I set SRS of layer as 5514, this layer shift on correct position. Source layer and screenshots are in attachment.

vrbr.zip - Shapefile (14 KB) Vladimír Hans, 2019-03-05 10:25 AM

vrbr.jpg - Screenshots of ArcGIS and QGIS (509 KB) Vladimír Hans, 2019-03-05 10:25 AM

vrbr-1.prj (542 Bytes) Vladimír Hans, 2019-03-06 02:41 PM

vrbr-2.prj (542 Bytes) Vladimír Hans, 2019-03-06 02:46 PM

vrbr-3.prj (547 Bytes) Vladimír Hans, 2019-03-06 02:49 PM

MaloplZCHU.prj - PRJ generated from ArcGIS (573 Bytes) Vladimír Hans, 2019-03-25 10:22 AM

History

#1 Updated by Giovanni Manghi about 1 year ago

  • Operating System deleted (Windows 7)
  • Status changed from Open to Feedback

Your shapefile loads with a custom CRS that has this definition

+proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813975277778 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +towgs84=589,76,480,0,0,0,0 +units=m +no_defs

while the real 5514 is

+proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813972222222 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +towgs84=542.5,89.2,456.9,5.517,2.275,5.516,6.96 +pm=greenwich +units=m +no_defs

that has 7 correction parameters, so is more precise.

#2 Updated by Vladimír Hans about 1 year ago

There is more complikated. In attachment are various prj file.

vbr-1.prj Polygon is in correct position, ["Azimuth",30.28813972222222]. QGIS didn't recognize srs, set custom srs.
vbr-2.prj Polygon is in correct position, ["Azimuth",30.28813975277778]. QGIS recognize SRS as 102067.
vbr-3.prj Polygon isn't in correct position, ["Azimuth",30.28813972222222], DATUM["D_S_JTSK"
I think that problem is in value "D_S_JTSK". If I change this value, polzgon move in correct position.

#3 Updated by Giovanni Manghi about 1 year ago

Vladimír Hans wrote:

There is more complikated. In attachment are various prj file.

vbr-1.prj Polygon is in correct position, ["Azimuth",30.28813972222222]. QGIS didn't recognize srs, set custom srs.
vbr-2.prj Polygon is in correct position, ["Azimuth",30.28813975277778]. QGIS recognize SRS as 102067.
vbr-3.prj Polygon isn't in correct position, ["Azimuth",30.28813972222222], DATUM["D_S_JTSK"
I think that problem is in value "D_S_JTSK". If I change this value, polzgon move in correct position.

maybe, but EPSG 5514 as QGIS knows/uses is

+proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813972222222 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +towgs84=542.5,89.2,456.9,5.517,2.275,5.516,6.96 +pm=greenwich +units=m +no_defs

#4 Updated by Vladimír Hans about 1 year ago

I tried to load shp with vbr-3.prj in QGIS 3.6.1 and layer wasn't shifting. It's great. But QGIS didn't recognize correct prj for SRS 102067. Probably there wos misunderstanding becouse vbr-3.prj was malformed by me. In attchment is prj file from ArcGIS for SRS 102067.

#5 Updated by Giovanni Manghi about 1 year ago

Vladimír Hans wrote:

I tried to load shp with vbr-3.prj in QGIS 3.6.1 and layer wasn't shifting. It's great. But QGIS didn't recognize correct prj for SRS 102067. Probably there wos misunderstanding becouse vbr-3.prj was malformed by me. In attchment is prj file from ArcGIS for SRS 102067.

102067 as QGIS knows is

+proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813972222222 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +towgs84=542.5,89.2,456.9,5.517,2.275,5.516,6.96 +pm=greenwich +units=m +no_defs

and not for example as

http://spatialreference.org/ref/esri/102067/proj4/

the former is more precise. If you have a layer with a CRS defined as with the latter then is also OK, but reprojecting it will not as precise as if it would use the former (also will not recognized as exactly 102067 by QGIS).

Also available in: Atom PDF