[GRASS5] Some Bugs

[Frank Warmerdam]

"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 suspect r.in.gdal will fallback to WGS84 LL as the assumed projection
in some cases where it can't work one out. 
 
> 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
> 
> 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?

> 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.

Markus asks:
>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...

The letter code doesn't have an effect on the underlying projection,
except in some software that checks the row code to see if the utm zone
is in the southern vs. northern hemisphere.  The row code is really just 
intended to help humans decide what map they need without looking over the
northings carefully. 

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerda
and watch the world go round - Rush    | Geospatial Programmer for Rent

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