[GRASS-dev] g.region print flags combination

[Maciej Sieczka]

Paul Kelly wrote:
> 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.

And I think :):

- g.region: should print region extent, *only*
- r.info: print only the given raster layer info, *exluding* projection
ifno - you can't have (normally) a raster inside a given GRASS
location, that has a projection different from the location's
projection it is in, can you?
- g.proj: print all the info relevant to the projection of the current
working location

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

What circumstances, ecxactly (sorry, I really don't know).

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

Hmm, I think g.proj -p should report the projection name as good as it
can, given the available data. 'Other' doesn't mean much (there are
dozens of projections other than UTM and State Plane).

Maciek

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

How can a raster's projection inside a location be different than the
location's projection?

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

Right. But it doesn't print the units information, which is present in
PROJ.4-compatible output of eg. "epsg_tr.py -proj4 <code>". Shouldn't
then g.proj -j include the units info too?

> 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 :)

Thanks! I hope together we can know a bit more :).

Maciek