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: | |
| Cc: |
Description (last modified by )
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
or
ogr2ogr -f "GML" -s_srs "epsg:2065" -t_srs "epsg:4326" out4326.gml in2065.gml
i get correct result with this projection specification:
wget http://spatialreference.org/ref/sr-org/czech-s-jtsk-epsg2065/esriwkt/ -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: http://gis.templ.net/gdal_2065_bug.tar.gz
Change History (8)
comment:1 by , 11 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 11 years ago
| Description: | modified (diff) |
|---|
comment:3 by , 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 http://crs.bkg.bund.de/crseu/crs/eu-countrysel.php?country=CZ )
comment:5 by , 11 years ago
| Resolution: | invalid |
|---|---|
| Status: | closed → reopened |
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: http://spatialreference.org/ref/sr-org/6635/prettywkt/
incorrect 2065: http://spatialreference.org/ref/epsg/2065/prettywkt/
correct patch use so MapTiler
comment:6 by , 11 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" (http://spatialreference.org/ref/sr-org/6635/prettywkt/) just looks like a hack (a working one...), whereas the "incorrect 2065" (http://spatialreference.org/ref/epsg/2065/prettywkt/) 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 , 11 years ago
For the sake of completness, this issue is also reported as http://trac.osgeo.org/postgis/ticket/1940 (where it has been patched) and http://trac.osgeo.org/proj/ticket/185
with regard to CZ/SK +towgs84 I use SRS +towgs84