[GRASS5] GRASS and lat/long with sphere

[Markus Neteler]

On Tue, Oct 01, 2002 at 02:31:31PM +0100, Glynn Clements wrote:
[...]
> > May I ask you to apply the change? As far as I understand it should
> > only users of "sphere" ellipsoid. So it is no severe change (I have
> > already another tester in mind, hi Alessandro F.!).
> 
> Done.

Thanks, Glynn!

> The following programs all contain direct references to functions
> whose names contain the words "ellipsoid" or "spheroid", and so are
> prime candidates for testing.
> 
> etc/bin/cmd:
> 	d.geodesic
yes, is calculating the distance (unfortunately only in miles)

> 	d.where
yes (compared to g.region -c).

[ but d.where -d
             EAST:             NORTH:
  -121239.87944942   7554345.52279129

  doesn't work in a UTM location!!]

> 	m.datum.shift
> 	m.gc2ll
> 	m.ll2gc
> 	m.ll2u
> 	m.region.ll
> 	m.tiger.region
> 	m.u2ll
... all untested.

> 	r.buffer
yes.

> 	r.in.ll
> 	r.in.utm
... both untested.

> 	r.surf.idw
yes.

> 	v.apply.census
> 	v.in.tig.basic
> 	v.in.tig.lndmk
> 	v.out.sdts
... all untested.

> etc/bin/inter:
> 	g.setproj
yes.

> 	m.proj
no in terms of 'sphere': it doesn't ask for ellipsoid when defining 'll'

>       m.proj2
Unclear to me:

I tried to convert Botswana coordinates with:
m.proj2 inproj="proj=utm,name=utm,ellps=wgs84,zone=35,unfact=1.0" \
outproj="proj=ll,ellps=wgs84,south" input=utm.coord output=new.ll.coord

In file 'utm.coord' I stored the UTM South coordinates:
255016.575000 7519449.975000

It prints:
Using in proj: +proj=utm +proj=utm +name=utm +a=6378137.0000000000
+es=0.0066943800 +zone=35 +unfact=1.0
Using out proj: +proj=ll +proj=ll +a=6378137.0000000000 +es=0.0066943800
+south
21:12:38.829844E 67:41:13.81965N

Expected result is (ellips = wgs84):
 24:37:10.851726E [24.61968]
 22:20:21.876491S [-22.33941]

Using 'sphere' I get
21:12:38.829844E 67:41:13.81965N
which is the same nonsense.

A general problem is that m.proj2 happily calculates coordinates even
if the specified keywords are mistyped :-(

---------
Another test with Gauss-Boaga, Italy coordinates:

GRASS:~ > g.region -c
region center northing: 5173900.000000
region center easting:  1697080.000000
GRASS:~ > g.region -l
Center Longitude: 11:34:34.913698E [11.57636]
Center latitude:  46:40:48.785419N [46.68022]

m.proj2
inproj="proj=tmerc,name=tmerc,ellps=international,x_0=1500000,k_0=0.9996,lon_0=9.0" \
outproj="proj=ll,ellps=wgs84" input=gk.coor output=new.ll.coord2

Result with wgs84 ellipsoid
11:34:38.225903E 46:41:19.429087N                                           

Result with sphere 'ellipsoid' (changed in above cmd line):
11:34:38.225903E 46:41:19.429087N

Oops. Identical.
So that doesn't seem to work properly (how many bugs here in m.proj2?).

Perhaps some more people could check m.proj2 functionality.

> The functions in question are:
> 
> CC_get_spheroid            
> CC_spheroid_name           
> CC_u2ll_spheroid           
> CC_u2ll_spheroid_parameters
> G_ellipsoid_name           
> G_get_ellipsoid_by_name    
> G_get_ellipsoid_parameters 
> G_get_spheroid_by_name     

Mhhh. Probably ok. The problems mentioned above seem to be only related to
module implementations.

But: I did another test with vector data:

- vector lines map
   - imported into ll/sphere location
   - imported into ll/wgs84 location
   - re-projected from ll/sphere location to UTM/wgs84 location
   - re-projected from ll/wgs84 location to UTM/wgs84 location

   Compared in UTM/wgs84 location both maps are identically geocoded
   although a different ellipsoid/sphere was specified. This looks
   strange to me.

So far my tests,

Markus