[GRASS-dev] g.region print flags combination

[Paul Kelly]

On Thu, 4 Jan 2007, Maciej Sieczka wrote:

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

G_projection() checks in there. E.g. checking for a latitude-longitude 
projection in a module to see how distance measurements should be handled, 
results in WIND being checked. Also for XY locations, they won't have a 
PROJ_INFO file, but the projection entry in the WIND file gives the 
information that the location is XY (unprojected). There are also places 
in the code code that check if the location zone and projection (from the 
WIND file) match that in raster map headers.

It would be possible to have the projection and zone info in a raster map 
not matching the location if it had got corrupted or manually edited, or 
more likely directly copied from a different location. It is possible for 
two locations to have effectively the same projection number but different 
numbers in the cellhd projection value - e.g. both UTM and State Plane 
projections can equivalently be represented as transverse mercator or 
lambert conformal conic with appropriate parameters, in which case there 
should be 99 (other projection) in the cellhd. Not that likely but 
possible.

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

Yes - I wasn't saying it shouldn't - my comment above is related to what I 
thought g.region should report. Well ideally it should report any 
projection-related information but if it's there in the WIND file, then I 
think it should.
My main point is, that to keep things simple and avoid the possiblity of 
introducing easily avoidable bugs in the future, the structure of the 
commands should reflect as much as possible the underlying structure of 
GRASS. Thus if you are going to change e.g. g.region and r.info not to 
report the projection info contained in the WIND file and raster header,
then you should remove that information from those files, change the 
cellhd struct not to contain it, and change all the bits of GRASS code 
that assume that information is there and check for it. IOW a proper 
clean-up.

I don't think it is a good idea to just make cosmetic changes to commands 
that hide the mess that is in the GRASS structure underneath, like 
sweeping it under the carpet. IMHO, better to keep it visible it will be 
easier to see what's going on and diagnose problems when they occur. But 
TBH I don't feel all that strongly on this issue really!

[...]
>>> [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?

Maybe it should! Can you point me to some examples?

Paul