[GRASS5] Re: m.proj
Helena
hmitaso at unity.ncsu.edu
Tue Jan 28 15:32:53 EST 2003
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
More information about the grass-dev
mailing list