Opened 12 years ago

Closed 11 years ago

#3579 closed defect (fixed)

lacking towgs84 for Pulkovo 1942(58), Poland

Reported by: msieczka Owned by: warmerdam
Priority: normal Milestone: 1.7.3
Component: OGR_SRS Version: svn-trunk
Severity: critical Keywords:
Cc: pkelly, Markus Neteler

Description

GDAL lacks towgs84 for all Pulkovo 1942(58)-based CRSs. I don't know how for other countries, but for Poland, i.e. all these EPSG codes:

3120 2172 2173 2174 2175 3333 3334 3335 3329 3330 3331 3332 3328 4179

it should be:

33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84

like it used to, couple of GDAL releases ago. This error has been introduced into GDAL somewhere after PROJ.4 4.6.1, which is the last PROJ.4 release with the `epsg' file not borked in this regard.

The bug affects PROJ.4, GRASS and other software dependant on GDAL CRS-support files (e.g. it would affect QGIS too, if they used this script: http://trac.osgeo.org/qgis/browser/trunk/qgis/scripts/qgis_srs.sh).

Change History (7)

comment:1 Changed 12 years ago by msieczka

Resolution: invalid
Status: newclosed

Oh, I can see this was fixed in GDAL on 2010-03-01 in r18978. Great.

Glad this also fixes http://trac.osgeo.org/proj/ticket/11! Thanks.

When is PROJ.4 going to be relased with a fixed `epsg' file?

comment:2 Changed 12 years ago by Even Rouault

Milestone: 1.7.21.8.0

I've added a regression test for you use case. See r19719

comment:3 in reply to:  1 Changed 12 years ago by msieczka

Milestone: 1.8.01.7.3
Resolution: invalid
Status: closedreopened

Replying to msieczka:

Oh, I can see this was fixed in GDAL on 2010-03-01 in r18978. Great.

But, that's only in trunk. Will the fix be backported to 1.7 stable branch?

When is PROJ.4 going to be relased with a fixed `epsg' file?

Is it going to be released?

comment:4 Changed 12 years ago by Even Rouault

IMHO, this isn't a good candidate be back-ported in 1.7 branch as it would cause a significant change of behaviour between 1.7.0 and 1.7.3. I recall a IRC chat with Markus Neteler where he mentionned for example that GRASS mechanism to let the user choose its datum shift isn't ready for the fact that there are many more datum shifts than before in the SRS expanded from the new EPSG database. But as Frank is much more aware of the impact&issues, I happily let him have the final word on this :-)

comment:5 in reply to:  4 ; Changed 12 years ago by msieczka

Cc: pkelly Markus Neteler added

Replying to rouault:

IMHO, this isn't a good candidate be back-ported in 1.7 branch as it would cause a significant change of behaviour between 1.7.0 and 1.7.3. I recall a IRC chat with Markus Neteler where he mentionned for example that GRASS mechanism to let the user choose its datum shift isn't ready for the fact that there are many more datum shifts than before in the SRS expanded from the new EPSG database.

GRASS keeps it's own copy of GDAL CRS support files. I guess that whether GDAL's own CRS support differ should not matter. Is that correct, Markus?

Regarding this Polish case, Paul Kelly has suggested a workaround for GRASS, which partially fixes the problem (http://lists.osgeo.org/pipermail/grass-dev/2010-May/050501.html).

If a full backport of the new datum logic from trunk to 1.7 is not an option, is it at least somehow possible to make GDAL again interpret the "Pulkovo 1942(58)" datum for Polish krassovsky-based CRSs (3120 2172 2173 2174 2175 3333 3334 3335 3329 3330 3331 3332 3328 4179) as "33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84"?

So that e.g. 'epsg_tr.py -proj4 2174' in 1.7 would again return a correct:

# Pulkovo 1942(58) / Poland zone IV
<2174> +proj=sterea +lat_0=51.67083333333333 +lon_0=16.67222222222222 +k=0.9998 +x_0=3703000
 +y_0=5627000 +ellps=krass +towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +units=m
 +no_defs  <>

instead of the current bogus:

# Pulkovo 1942(58) / Poland zone IV
<2174> +proj=sterea +lat_0=51.67083333333333 +lon_0=16.67222222222222 +k=0.9998 +x_0=3703000
 +y_0=5627000 +ellps=krass +units=m +no_defs  <>

?

Another thing are Polish GRS80-based CRSs. What would it take to force GDAL 1.7 to use towgs84=0,0,0 for EPSG 2176-2179, 2180, so that for e.g. 'epsg_tr.py -proj4 2180' it would print:

# ETRS89 / Poland CS92
<2180> +proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 +ellps=GRS80
 +towgs84=0,0,0 +units=m +no_defs  <>

instead of the wrong one:

$ epsg_tr.py -proj4 2180
# ETRS89 / Poland CS92
<2180> +proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 +ellps=GRS80 +units=m
 +no_defs  <>

?

This regression (if I remember well, these issues were not there in some past GDAL releases) is quite a problem for Polish users of software which depend on GDAL. It brakes CRS support for users of QGIS, PROJ.4 (as it's epsg file is derived from GDAL, thus the latest release also has towgs84 missing from all Polish CRSs), MapServer? etc.

comment:6 in reply to:  5 Changed 11 years ago by msieczka

Replying to msieczka:

This regression (if I remember well, these issues were not there in some past GDAL releases)

Doblechecked: the last version without this issue is GDAL 1.6.3. The issue is present in 1.7.1, 1.7.2 and the current stable SVN branch.

comment:7 Changed 11 years ago by Even Rouault

Resolution: fixed
Status: reopenedclosed

r19810 /branches/1.7/gdal/data/gcs.override.csv: Override EPSG:4179 (Pulkovo 1942(58)) and EPSG:4258 (ETRS89) to add towgs84 transform for Polish CRS (#3579)

Note: See TracTickets for help on using tickets.