[GRASS5] Re: m.proj

[Helena]

I would vote for m.proj to be removed because it does not work with
GRASS data,
but it may be useful to put somewhere information about cs2cs (which I
did not know
about). Maybe keep m.proj in the manual for some time with a note that
it was
retired and people should use cs2cs (where do you get it?) 
The best place of course for this (and other essential non-GRASS tools)
would be in an on-line GRASS tutorial if it ever happens.
But this is just my opinion (I have never used m.proj except for the
book)

Helena

Markus Neteler wrote:
> 
> 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
> 
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5