Shift layer from ArcGIS, SRS 5514

[qgib]

Author Name: Vladimír Hans (Vladimír Hans)
Original Redmine Issue: 21477
Affected QGIS version: 3.7(master)
Redmine category:projection_support

---

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 (Vladimír Hans)
• vrbr.jpg (Vladimír Hans)
• vrbr-1.prj (Vladimír Hans)
• vrbr-2.prj (Vladimír Hans)
• vrbr-3.prj (Vladimír Hans)
• MaloplZCHU.prj (Vladimír Hans)

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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.

---

• operating_system was changed from Windows 7 to
• status_id was changed from Open to Feedback

[qgib]

Author Name: Vladimír Hans (Vladimír Hans)

---

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.

---

• 14535 was configured as vrbr-2.prj
• 14536 was configured as vrbr-3.prj
• 14534 was configured as vrbr-1.prj

---

• vrbr-2.prj (Vladimír Hans)
• vrbr-3.prj (Vladimír Hans)
• vrbr-1.prj (Vladimír Hans)

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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

[qgib]

Author Name: Vladimír Hans (Vladimír Hans)

---

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.

---

• 14667 was configured as MaloplZCHU.prj

---

• MaloplZCHU.prj (Vladimír Hans) - PRJ generated from ArcGIS

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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

[nyalldawson]

This should be resolved in 3.8 and builds based on proj 6 -- if not, it's an issue in the proj library, not QGIS