[GRASS5] Some Bugs

GRASS GRASS developer
,
1

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:

proj: 1
zone: 0

When the zone *should* be 10. And the projection should be whatever the
correct number is for UTM. I verified this problem by generating a
raster using r.surf.random in a dataset have a PROJ_INFO of:

name: UTM
datum: nad83
dx: 0.000000
dy: 0.000000
dz: 0.000000
proj: utm
ellps: GRS80
a: 6378137.0000000000
es: 0.0066943800
f: 298.2572221010
zone: 10

However, the cellhd file for the raster reads:

proj: 1
zone: 0
north: 4000000
south: 3999000
east: 501000
west: 500000
cols: 100
rows: 100
e-w resol: 10
n-s resol: 10
format: -1
compressed: 1

We definitely need to track down and correct this before a final
release. I find it suspicious that the PROJ_INFO file in this
location has "proj: utm" instead of a number.

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

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

2

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

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?

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.

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

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

3

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@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

On Wed, 13 Dec 2000, Eric G . Miller wrote:

If there's some reason for having both upper and lowercase names for
these, can't we just "alias" the names somehow?

Having duplicate upper and lower case entries in etc/ellipsoids would be
the fast and ugly hack. Going to lower case only is what most people would
prefer, but that would also mean fixing PROJ_INFO entries for existing
locations.

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?

I think everyone who has tracked the code in g.setproj and associated
modules will agree its an ugly mess. There is nothing special about UTM -
PROJ could handle it as any other projection, but _only_ for historical
reasons it's treated separately. Changing it is not easy though, as it
means changing all 'wrapper' code in all modules that treats UTM and LL
differently.

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 agree something has to be done, but I would hesitate to start messing
with it before 5.0 is out. A redesign during 5.1 I feel is more
appropriate.

By the way, how far are we from dynamic projections? I could imagine
storing data in geocentric coordinates and only projecting when the user
needs a flat surface image (screen/printer/export) is feasable with the
processing power of computers today. Perhaps first as specially flagged
locations to keep backward compatibility. This could open up new
possibilities such as animated remorphing of maps through different
projections.

regards
Morten Hulden

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

5

"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@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@geog.uni-hannover.de with
subject 'unsubscribe grass5'

6

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@geog.uni-hannover.de with
subject 'unsubscribe grass5'

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

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

7

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@jps.net>

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

8

Hi all.

Andreas Lange wrote:

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.

I guess I'll throw in my 2 cents here. Please note that I am not a GIS
person, so my point of view is as a software engineer.

I agree that it is important to point out the difficulties in making
such a change in the software, but we also need to encourage anyone
willing to tackle this change (even if they only offer to see how
feasible it is). Pointing out the difficulties is sometimes enough to
discourage people from looking further.

In this case, I feel we need more information before we can decide if
this change is feasible. A software engineering priciple is that
anything that simplifies the use of the software for users is
"generally" worth the effort needed to implement it providing it doesn't
substantially degrade performance. Also, this change has the potential
to simplify the code. Thus, there are two important reasons for
considering this change.

I guess I just don't want to see this idea die simply because it
involves a major change to the source code. The advantages from a
software engineering point of view justify IMHO a more detailed
investigation into the feasibility of making this change.

But of course, this idea is moot if we don't have any volunteers to
perform this investigation. :slight_smile:

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

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

9

Hi Justin,

it was not my intention to deter someone from working on this :-).
But i looked into this back in summer when i investigated the datum
transformation stuff and detected that it would require a complete
library redesign and to adapt _all_ modules to this redesign. Please
note what that means: rewriting all modules that depend on projection
support. It could be feasible to create a new library in parallel with
the new projection/datum support and to adapt the modules step-by-step.

I agree that a unified projection support would simplify programming
very much. The user would not directly see this, but get a much more
advanced projection support.

cu,

Andreas

Justin Hickey wrote:

I agree that it is important to point out the difficulties in making
such a change in the software, but we also need to encourage anyone
willing to tackle this change (even if they only offer to see how
feasible it is). Pointing out the difficulties is sometimes enough to
discourage people from looking further.

In this case, I feel we need more information before we can decide if
this change is feasible. A software engineering priciple is that
anything that simplifies the use of the software for users is
"generally" worth the effort needed to implement it providing it doesn't
substantially degrade performance. Also, this change has the potential
to simplify the code. Thus, there are two important reasons for
considering this change.

I guess I just don't want to see this idea die simply because it
involves a major change to the source code. The advantages from a
software engineering point of view justify IMHO a more detailed
investigation into the feasibility of making this change.

But of course, this idea is moot if we don't have any volunteers to
perform this investigation. :slight_smile:

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

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