Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUG epsg 31253 WRONG towgs84 transformation parameters #254

Closed
proj4-bot opened this issue May 22, 2015 · 2 comments
Closed

BUG epsg 31253 WRONG towgs84 transformation parameters #254

proj4-bot opened this issue May 22, 2015 · 2 comments

Comments

@proj4-bot
Copy link

Reported by mdiener on 26 Jan 2015 07:19 UTC
proper settings should be for EPSG 31253, 31252, 31251
+towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232

I have contacted the ESPG.org people and Roger Lott repsponded with this great email...see below

A brief technical summary:

     EPSG::31253 is a projected CRS for (the eastern part of) Austria.

     The transformation with parameter values 682,-203,480 is a transformation from the US National Geospatial Intelligence Agency (NGA). We carry this in the EPSG Dataset as EPSG::3962. It is  applicable to former Yugoslavia. It is not applicable to Austria.

     The transformation with parameter values 577.326,90.129,463.919,5.137,1.474,5.297,2.4232 is an official transformation from the national mapping agency of Austria. We carry this in the EPSG Dataset as EPSG::1618. For anyone defining early binding strings it is appropriate to define it with CRS EPSG::31253, as well as with EPSG::31252, EPSG::31251 and others.

     As a matter of principle transformations should only be applied to areas that fall within the area of intersection of their source and target geographic CRSs. EPSG supplies polygons describing these areas. Had these been used in the construction of the proj.4 string it should have been seen that the area associated with CRS 31253 (EPSG polygon code 1708) and the area associated with transformation 3962 (EPSG polygon code 2370) do not intersect, so the two should not have been bound together.

If you think it will help feel free to copy this message to them. Roger Lott, IOGP Geodesy Subcommittee

Migrated-From: https://trac.osgeo.org/proj/ticket/254

@proj4-bot
Copy link
Author

Modified by mdiener on 26 Jan 2015 07:19 UTC

@rouault
Copy link
Member

rouault commented Jan 10, 2017

Fixed in https://trac.osgeo.org/geotiff/changeset/2748

Updated epsg file will come with EPSG v9 upgrade: #477

@rouault rouault closed this as completed Jan 10, 2017
@rouault rouault added this to the 4.9.4 milestone Jan 10, 2017
@kbevers kbevers modified the milestones: 5.0.0-b, 5.0.0 Feb 1, 2018
miurahr pushed a commit to miurahr/libgeotiff that referenced this issue Feb 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants