[GRASS-dev] g.region print flags combination

[Paul Kelly]

Hello Maciek

On Thu, 4 Jan 2007, Maciej Sieczka wrote:

> Wait, another thought - WHY should g.region print the projection info,
> either in -p or -pg mode, *anyway*? Isn't ther g.proj -p for that?
> Doubled functionality per se (if we also consider r.info which prints
> the projection info too - a trippled fuctionality). So shouldn't this
> wait for GRASS 7, where printing the projection info will be left for
> g.proj [1] alone, and removed from g.region and r.info for good? And
> for now, in GRASS 6, leave it as it was before - not perfect, but 100%
> backwards compatible at least. Let's leave cleaning it all up together
> for GRASS 7. Am I thinking any good? Paul?

I think:
g.region should print only information it gets from the WIND file
r.info should print only information it gets from the raster header file
g.proj -p should only print information it gets from the PROJ_INFO and 
PROJ_UNITS files.

Yes the WIND and yes the raster header include some projection information 
- that is an historical thing. We shouldn't try to hide it though, because 
there are bits of the code that check it and it is still useful in a few 
circumstances. But I don't think extra stuff like the projection name from 
PROJ_INFO in brackets, ellps or datum should be there. It is confusing as 
these are being taken from a different source. The projection name 
reported should be one of the 5 original ones defined: XY, UTM, State 
Plane, Latitude-Longitude or Other, corresponding to codes 0,1,2,3 or 99 
in the WIND file.

r.info should continue to report the projection information that is in the 
raster header - it causes problems if it is not the same as the location 
so it is important to report it just in case. But again (I don't know if 
it does) it should not report anything from the PROJ_INFO file.

> [1]
> propably the g.proj -j output should be extended to include all the
> information output by g.proj -p, or a new "-g" flag should be
> introduced, to be used in conjunction with "-p" for parseable output.

Hmm, if you think it might be useful. I'm not sure. The function of
g.proj -j is to produce a PROJ.4-compatible output. This is slightly 
different from that you see with g.proj -p with colons replaced by = 
signs. I'm not sure how useful g.proj -pg would be as AFAIK only proj, 
unit, units and meters are the only fields *guaranteed* to be present. 
There are many different ways to specify a PROJ_INFO file, unlike a WIND 
file where all the parameters have to be there and have to have a value. 
The two aren't really analogous IMHO.

So that's what I think :)

Paul