[GRASS5] Some Bugs

[Andreas Lange]

Hi 2 all,

i remember that i made some user requests on the ellipsoids and datums
case-insensitive, as they were before case-sensitive (e. g. entering
wgs84 instead of WGS84 was an error). But i must admit that i am not
shure how it is handled internally in the gis lib. If i remember correct
that was only done for comparisons, so that it should not have any
negative side-effects.

For the UTM/ll/proj handling in GRASS: I would not recommend to change
this, as i fear no one currently overlooks the consequences and the
parts that must be changed. This will give many incompatibilities to the
data. 
The general problem is, as Frank and Morten told, that ll, utm and
"other projections" are handled different throughout the whole GRASS.
Changing this would require a total library re-design. 

Andreas

Markus Neteler wrote:
> 
> Eric and Frank Warmerdam,
> 
> On Wed, Dec 13, 2000 at 12:09:05AM -0800, Eric G . Miller wrote:
> > On Mon, Dec 11, 2000 at 12:17:34AM -0800, Eric G . Miller wrote:
> > > Okay, So I got around to installing libgeotiff and libgdal, so I could
> > > try r.in.gdal.  Well, it incorrectly identifies the projection.  I think
> > > the problem may be related to some of the projection info functions
> > > since I subsequently discovered all of the files I had been working with
> > > in a particular dataset have:
> >
> > Okay, I'll refile this as a bug against r.in.gdal, since after some
> > futzing around, I couldn't reproduce whatever led up to my losing the
> > "zone" information. r.in.gdal seems to think this projection is 'll'
> > with WGS84 ellipsoid, but g.region -p gives:
> >
> > projection: 1 (UTM)
> > zone:       10
> > datum:      nad83
> > ellipsoid:  GRS80
> > north:      4287336.36938346
> > south:      4286992.24959761
> > west:       702638.44204432
> > east:       703010.87980807
> > nsres:      0.39782634
> > ewres:      0.38876593
> > rows:       865
> > cols:       958
> Frank, may I ask you to give us a hint?
> 
> >
> > While I'm thinking about it; why do we have ellipsoids GRS80/grs80 etc.?
> > Aren't they the same?  And if so, why does specifying ellipsoid=grs80
> > and then specifying datum=nad83 generate an error?  If there's some
> > reason for having both upper and lowercase names for these,
> > can't we just "alias" the names somehow?
> Eric,
> 
> actually I can't find grs80 in the lists...
> However, I agree to support lowercase names only. Additionally the routine
> reading in the ellipsoid/ etc. should always change the input
> letters of the user to lowercase.
> 
> If there are no objections, I will change
> src/libes/gis/ellipse.table
> to lowercase names.
> 
> > And to be even more of a pest.  Is there something special about UTM?
> > why should it be handled differently than all the other projections?
> > Seems we should have:
> > XY data (unreferenced)
> > Unprojected (lat/lon)
> > Projected (projection)
> >
> > I know there's a hysterical (I mean historical) reason for this, but it
> > would seem logical to do this.
> Again I agree. Should be more clear here. Maybe UTM and States Plane
> was an extra entry as GRASS has been an U.S. only development. But
> nowadays in worldwide use you proposal is more intuitive.
> 
> Related question to UTM: Why is the Zone letter not required (sorry, I am
> no UTM expert). For Germany it is 32U, but GRASS only wants to know 32.
> This I don't understand...
> 
> Markus
> 
> ----------------------------------------
> If you want to unsubscribe from GRASS Development Team mailing list write to:
> minordomo at geog.uni-hannover.de with
> subject 'unsubscribe grass5'

-- 
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange at Rhein-Main.de - A.C.Lange at GMX.net



---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'