[GRASS5] Some Bugs

[Eric G . Miller]

On Wed, Dec 13, 2000 at 08:54:04AM -0500, Frank Warmerdam wrote:
> "Eric G . Miller" wrote:
> > 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:
> 
> Eric, 
> 
> I haven't been following the GRASS list, or your problem closely.   
> What was the context?  Is there a bug report registered somewhere with
> all the details?

I actually haven't "filed" a bug.  I like to find out if other people
can confirm behavior before I make it "official", hence it was only
"filed" on the list.

> I suspect r.in.gdal will fallback to WGS84 LL as the assumed projection
> in some cases where it can't work one out. 

That's what I guessed, but I'm wondering why it has problems determining
projection/datum info in this context (There's nothing unusual about the
projection and datum in the case where I got this error).

> > While I'm thinking about it; why do we have ellipsoids GRS80/grs80 etc.?
> > Aren't they the same?  
> 
> Part of the problem is that r.in.gdal takes a generic PROJ.4 
> representation of the projection, and tries to massage it a bit 
> to be suitable for GRASS.  PROJ.4 is case insensitive about ellipsoid
> names, and so my code happens to produce "grs80" instead of "GRS80". 
> 
> I think the most important thing is to ensure that GRASS remains case
> insensitive.  It shouldn't matter too much what appears in upper or
> lower case as long as it has no effect.
> 
> > And if so, why does specifying ellipsoid=grs80
> > and then specifying datum=nad83 generate an error?  
> 
> Where does this cause an error?

I should've been more clear.  The grs80/GRS80 crops up in initializing a
new location (g.setproj ??).  I wasn't thinking of r.in.gdal too much at
this point.

> > 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.
> 
> I would agree, but it is of course a historical development issue.  In 
> the old days UTM, LL and then state plane were the only projections.  Then
> type 99 (other) was added to generically handle other projections. 
> 
> I don't think it is worth changing this in 5.1 unless we are making a
> major pass through all the projections code.  One thing I would like to
> caution against is generating large amounts of work to achieve minor
> internal cleanup at the risk of potentially substantial unforeseen 
> compatibility issues.

Well, I certainly wasn't going to jump on such a change immediately.
This is more a wishlist thing for logical consistency.

-- 
Eric G. Miller <egm2 at jps.net>

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