lacking towgs84 for Pulkovo 1942(58), Poland

[msieczka]

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

[msieczka]

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?

[Even Rouault]

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

[msieczka]

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?

[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 :-)

[msieczka]

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.

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

[Even Rouault]

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)