[Proj] Using EPSG codes with cs2cs (the one who asked: Amro_rt_rps)

[Mohammad Amro]

Hi all,

Sorry for my late response ... my post in the forum is not yet accepted but I received the replies in the digest :), so I hope this will reach all who helped.


First of all, wow, I am just impressed with the number of sincere and supportive people in this forum.

I have gone through each and every reply and going to tell my input:

@  Bob (Fischer, Robert P. (GISS-6110)[COLUMBIA UNIVERSITY]) said:

"Have you tried using the version of proj.4 that comes with Ubuntu (apt-get install proj)?

http://packages.ubuntu.com/search?keywords=proj

-- Bob"

Yes, but the version there is 4.7.0 (i.e., older). So I sticked to the newer one in Proj. 4 web site. 


Janne (support.mn at elisanet.fi) said:

it looks like the library cannot find some files it needs. Either your
path to the files is not correct or your files are not where they should
be. Make sure the path to the files is what it should be.. either by
fixing the path string or relocating the files?

Janne

Thanks for helping on interpreting this error, the EPSG 31495 is not listed as explained in great details by Miakel Rittri: "epsg: 31494   "DHDN / Germany zone 4" (deleted)" ... 

Jose Gon?alves said: 


1- Are you sure of EPSG code 31495? In my epsg file, installed with proj, I
can find only:

epsg: 31461    # DHDN / 3-degree Gauss zone 1 (deprecated)
.
.
.
epsg: 31469    # DHDN / 3-degree Gauss-Kruger zone 5

If a projection ID is not in the file the expected answer is the one you
got. It is not a configuration problem.
Check http://spatialreference.org to check the epsg code

2- In addition to my previous e-mail, since you have your own datum shift
parameters it is better to write the full proj string, instead of using an
epsg predefinition. Your rotation angles are in radians but cs2cs expects
arc-seconds. They become 1.04, 0.35, -3.08.
According to the map projection definition you give, the command line
should be something like:

cs2cs +init=epsg:4326 +to +ellps=bessel +proj=tmerc +lon_0=12 +x_0=4500000
+towgs84=582,105,414,1.040,0.350,-3.080,8.3
13.755944 51.054555
4623218.81      5659181.06 -46.16

Jose Gon?alves

1- Yes, the zone is listed in my WKT.ini file, but as explained in great details by Miakel Rittri: "epsg: 31494   "DHDN / Germany zone 4" (deleted)" ... 

2- Many thanks for this command line, in fact the resulting coordinates are faraway by around 118 meters for Xs and 141 meters for Ys. So, I am considering to do an offset and be happy with a margin of error <±2 meters, especially, I am considering an area of 3x3 Kms in Dresden.


Mikael Rittri said: 


"However, strangely enough, there is a third, semi-possible code

epsg: 31494   "DHDN / Germany zone 4" (deleted)

but note that it should end with 94, not 95, for zone 4.

More generally, to handle EPSG codes 31491 to 31495, you must turn the 9 upside down!
But this is not an old typo. The codes with 9s used to be the EPSG codes for the German
zones, but they were deprecated in the olden days when EPSG had the unfortunate habit
of deleting erroneous entries from the database. (This was the practice before July 2001;
see http://www.epsg.org/guides/docs/G7-1.pdf , footnote on p. 33).

I think the reason at the time for deprecating/deleting them, was only to change the
names, replacing "Germany" by "3-degree Gauss".  Possibly also to correct the grammar
error in the datum name (your WKT has Deutsche instead of Deutsches in the datum
name).

But ESRI continued to support the deleted codes ( http://support.esri.de/files/support/FAQs.pdf ),
so you can still see them used, even though they are no longer in the EPSG database.
They are not supported by Proj.4 or listed on spatialreference.org. Hm, I wonder if supporting
them could be a violation of EPSG Terms of Use, paragraph 6.7:

> 6.7. No data that has been modified other than as permitted in these Terms of Use shall be attributed to the EPSG Dataset.

Anyway, in 2001, the EPSG codes 31461 to 31465 were deprecated, too. Code 31461, zone 1,
was deprecated because "ProjCRS zone not used", and wasn't replaced until much later.
Codes 31462 to 31465, zones 2 to 5, were deprecated because "ProjCRS related to
inappropriate Coordinate system resulting in incorrect axes and name", and replaced
with EPSG codes 31466 to 31469.
    (The deprecated entries were assigned the axes Easting (X) and Northing (Y)
in that order, so they are right-handed systems. The corrected entries have the axes
Northing (X) and Easting (Y) in that order, so they are left handed systems, and X goes north.)

Poor little zone 1 wasn't rehabilitated until July 2011, when epsg:5520 was added,
which is also as a left-handed system with Northing (X) followed by Easting (Y).

Finally, early in 2012, new right-handed variants of all these systems were reintroduced
(EPSG Change Request 2011.104), but the new ones are not yet in Proj.4 or spatialreference.org.
In the new right-handed variants, the axes are abbreviated E and N instead of X and Y.

epsg:5676   "DHDN / 3-degree Gauss-Kruger zone 2 (E-N)"
epsg:5677   "DHDN / 3-degree Gauss-Kruger zone 3 (E-N)"
epsg:5678   "DHDN / 3-degree Gauss-Kruger zone 4 (E-N)"
epsg:5679   "DHDN / 3-degree Gauss-Kruger zone 5 (E-N)"
epsg:5680   "DHDN / 3-degree Gauss-Kruger zone 1 (E-N)"



2- Then, a better alternative could be to use the grid shift file BETA2007.gsb. It is not distributed with Proj.4,
but you can find a link at http://trac.osgeo.org/proj/ under Download, Datum shift grids.

If you download it to the directory where the other grid shift files are in Proj.4 (the nad directory),
then you can do

>cs2cs +init=epsg:4326 +to +ellps=bessel +proj=tmerc +lon_0=12 +x_0=4500000 +nadgrids=BETA2007.gsb

13.755944 51.054555

4623220.44      5659181.52 0.00

This result differs by about 1.7 meters from Jose's example.

3- The BETA2007.gsb file is claimed to give submeter accuracy,
"eine Koordinatengenauigkeit im Submeterbereich". (But maybe it
is still possible that the 7-parameter transformation you cite is more
accurate locally around Dresden.)


Mikael Rittri 


1- Many thanks Mikael for this rich and helpful information, now I understand much better how these things work. 

2- Strangely, I tried this datum shifts but I got worse results (as you said shifted by 1.7 meters) than if I don't use them.
3- Using the 7-parameters as highlighted by Jose Gon?alves gave me better results (by 1.7 meters), so, may be there is no better way to do it than offsetting the different and be happy with that. May be the tool I am using (closed box) is following different methods for conversion?!    


e.g., Long:  13.755944, Lat: 51.0545555

Tools coordinates:
4623100    5659040

7-parameters (X is shifted: 118 m, and Y is shifted 140 m)::

4623218.84    5659181.12
BETA2007 Datum shifts (X is shifted: 120 m, and Y is shifted 140 m):
4623220.44    5659181.52

Anyway, I think, as I am doing this conversion on a small scale area, then a linear offset (-118m, -140m) would result in <±2 meters which is the best I can go with until as you said the 2012 new modifications come to Proj.4.

One last question to all, how do I revers the conversion from X/Y Cartesian to Long/Lat Geographical?

A huge thanks you,
Mohammad Amro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20120509/46808dc6/attachment.htm