Opened 11 years ago

Closed 6 years ago

#4762 closed defect (fixed)

epsg:2065 projection is incorrect

Reported by: 6896896 Owned by: warmerdam
Priority: normal Milestone:
Component: default Version: unspecified
Severity: normal Keywords:

Description (last modified by 6896896)

when using epsg:2065 projection with ogr2ogr (gdal version 1.9.1), i get invalid results:

ogr2ogr -f "GML" -s_srs "epsg:2065" -t_srs "epsg:102067" out102067.gml in2065.gml


ogr2ogr -f "GML" -s_srs "epsg:2065" -t_srs "epsg:4326" out4326.gml in2065.gml

i get correct result with this projection specification:

wget -O 2065.prf

ogr2ogr -f "GML" -s_srs 2065.prf -t_srs "epsg:102067" out102067.gml in2065.gml

ogr2ogr -f "GML" -s_srs 2065.prf -t_srs "epsg:4326" out4326.gml in2065.gml

example in:

Change History (8)

comment:1 by 6896896, 11 years ago

Description: modified (diff)

comment:2 by 6896896, 11 years ago

Description: modified (diff)

with regard to CZ/SK +towgs84 I use SRS +towgs84

comment:3 by Even Rouault, 11 years ago

The difference is that with EPSG:2065, we have TOWGS84[589,76,480,0,0,0,0], whereas with the 2065.prf, we have TOWGS84[570.8,85.7,462.8,4.998,1.587,5.261,3.56]]

589,76,480,0,0,0,0 is tagged as the preferred parameter set from the S-JTSK (Ferro) GEOGCS to 4326 in data/datum_shift.csv and the corresponding validity area is the one indicated in the EPSG registry for EPSG:2065, that must be the one for the whole Czech Republik / Slovakia region. So I'd say the shift parameters selected by GDAL are consistant. However, in your particular case, it might well be that 570.8,85.7,462.8,4.998,1.587,5.261,3.56 is a better fit for your dataset if it is only/mainly located in Czech Republik (since it is the parameter set advertized in )

comment:4 by Even Rouault, 10 years ago

Resolution: invalid
Status: newclosed

IMO not a bug. Closing

comment:5 by 6896896, 10 years ago

Resolution: invalid
Status: closedreopened

Main problem is not +towgs (buggy +towgs get cca 100m difference). I think, problem is IMHO with axis definition and this get difference 2500 km.

Please test transform 2065 (file in2065.gml is grep of original cadastral data) to 102067/4326 or see example. I add Czech republic boundary for illustration(cr102067/cr4326.shp).

correct 2065:

incorrect 2065:

correct patch use so MapTiler

comment:6 by Even Rouault, 10 years ago

Oh I didn't realize that the issue was more significant that a single shift error... Well, I'm afraid I'm incompetent here, because there are several issues that probably combine with each other: the axis order in the GML file + the usual issues with Krovak ... What you call the "correct 2065" ( just looks like a hack (a working one...), whereas the "incorrect 2065" ( seems OK. The issue is probably that GDAL doesn't do the necessary axis swapping and/or coordinate sign inversions at some point, hence the need for the hacky WKT file.

comment:7 by Even Rouault, 10 years ago

For the sake of completness, this issue is also reported as (where it has been patched) and

comment:8 by Even Rouault, 6 years ago

Resolution: fixed
Status: reopenedclosed

In 37081:

Update to EPSG v9.0 database + datum shift overrides for EPSG:4149 (CH1903), EPSG:3844 (Pulkovo 1942(58) / Stereo70 Romania), EPSG:31251,31252,31253 (MGI (Ferro) / Austria), EPSG:2397/2398/2399 (Pulkovo 1942(83) / 3-degree Gauss-Kruger zone 3,4,5), EPSG:2065 (S-JTSK (Ferro) / Krovak) (fixes #4762, #6772)

Note: See TracTickets for help on using tickets.