[GRASS5] Re: m.proj

[Markus Neteler]

Hello Paul,

(cc to 'grass5' as it is of general interest)

On Mon, Jan 27, 2003 at 10:40:34AM +0000, Paul Kelly wrote:
> Hello Markus
> >From what I can see m.proj does the same thing as the proj or cs2cs
> programs included with the PROJ.4 library. Does it pre-date its general
> availability or is there something else it does that I have missed?

The m.proj is there for a long time, maybe as a sort of convenient
tool for 'proj'.
The problem is that results calculated with m.proj/m.proj2 (this is the cmd
version) are shifted by around 100m.

> Do you have any examples of what people use it for?

Yes: E.G. they have a paper map in a different projection (for
example in Germany UTM and Gauss-Krueger are used in parallel).
to check points etc some users use m.proj (maybe because they
don't know that nowadays the nice 'cs2cs' exists).

Then people may also use it to reproject point lists from GPS devices etc.
before importing them with s.proj.

> It may be simpler to re-write it using most of the code from cs2cs, but
> that seems a bit pointless.

Sounds right. But then we should think about removing m.proj[2]
from CVS to avoid that some people continue to use it and receive
shifted point data.

> If m.proj doesn't actually operate on files in the GRASS database but uses
> external text files, should it be there at all.....

This might be discussed on 'grass5' if we want to support that
in general in future. The problem is that many users take results for
truth when working with GRASS tools. So I feel that it is dangerous
when the results from m.proj[2] and cs2cs differ.

An example: UTM Zone 32-> Gauss-Krueger (Transverse Mercator)
# proj/nad/epsg
# DHDN / Germany zone 3
# datum from:
# http://www.colorado.Edu/geography/gcraft/notes/datum/dlist.html
cs2cs +init=epsg:32632 +to +init=epsg:31493 +towgs84=606,23,413
486000 5912000 0
3486066.49      5913928.42 6.189

(this result is rather identical to other proprietary software, it differs
 by some tens of centimeters)

m.proj delivers:

Initializing INPUT PROJECTION:
Please specify projection name
>utm
Initializing INPUT projection ELLIPSOID:
>wgs84
    Enter INPUT Projection Zone [zone] : 32
INPUT Projection: Would you like to use South Hemisphere (y/[n]) ? n
Enter plural for INPUT units [meters]:
Parameters used in INPUT projection:
         +proj=utm +a=6378137.0000000000 +es=0.0066943800 +zone=32 +unfact=1.0000000000
 
Initializing OUTPUT PROJECTION:
Please specify projection name
>tmerc
Initializing OUTPUT projection ELLIPSOID:
Please specify ellipsoid name
>bessel
  Enter OUTPUT Central Parallel [lat_0] (23N) : 0N
  Enter OUTPUT Central Meridian [lon_0] (96W) : 9E
    Enter OUTPUT Scale Factor at the Central Meridian [k_0] (1.000000) :
    Enter OUTPUT False Easting [x_0] (0.000000) : 3500000
    Enter OUTPUT False Northing [y_0] (0.000000) :
Enter plural for OUTPUT units [meters]:
Parameters used in OUTPUT projection:
         +proj=tmerc +a=6377397.1550000003 +es=0.0066743722
+lat_0=0.0000000000 +lon_0=9.0000000000 +k=1.0000000000
+x_0=3500000.0000000000 +y_0=0.0000000000 +unfact=1.0000000000

    Universe Transverse Mercator -> Transverse Mercator  Conversion:
        X_in (meters)   Y_in (meters)   X_out (meters)  Y_out (meters)
        ------------    -----------     -------------   -------------
 486000.00      5912000.00      3485996.11      5913755.52

-----------
Differences cs2cs/m.proj:
3486066.49-3485996.11=70.38
5913928.42-5913755.52=172.9

So the results of m.proj/m.proj2 are shifted as expected.

As conclusion:
 Is it right that either m.proj/m.proj2 should ask for the
 datum (and pass to proj) or both commands be removed?

Markus