[GRASS5] Re: m.proj

[Markus Neteler]

On Tue, Jan 28, 2003 at 03:32:53PM -0500, Helena wrote:
> 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).

So, now we have 2 votes to remove it, no other votes.
Other opinions?

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

You get it here:

http://www.remotesensing.org/proj/
PROJ4 software

Paul Kelly added recently a hint to m.proj2 html page that it supports
datum transformation.
But m.proj doesn't.

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

This list is already there:
http://grass.itc.it/
 Menu: Related projects

[ok, the cs2cs hint I have added today]

Markus

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