[GRASS5] Re: m.proj
neteler at itc.it
Wed Jan 29 04:15:10 EST 2003
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.
> 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:
Paul Kelly added recently a hint to m.proj2 html page that it supports
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:
Menu: Related projects
[ok, the cs2cs hint I have added today]
> But this is just my opinion (I have never used m.proj except for the
> 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
> > 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 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
More information about the grass-dev