[GRASS-dev] way to create PROJ_INFO and PROJ_UNITS

[Paul Kelly]

On Mon, 25 Feb 2008, andrea antonello wrote:

> Thanks,
> I didn't notice the "modifies current location unless 'location'
> option specified".
>
> I would like to try once more to start a discussion about
> standardization (or call it whatever you want) of the projection
> information.
> All projects that are not using proj have problems to guess and
> reconstruct the projection of a GRASS workspace.

Can you give some specific examples? I think "all" sounds like a bit of a 
generalisation. What is wrong with the internal GRASS functions 
GPJ_grass_to_wkt() and GPJ_grass_to_osr()? Or the -p, -d, -j, -w and -e 
options of g.proj? The GRASS representation can be converted to PROJ.4 
format without using any external libraries at all, and to WKT format 
using the OGR libraries of GDAL. PROJ.4 is not required at all for 
converting to either of those.

> Would it be possible to create also a PROJ_INFO.WKT well known text
> version of the file whenever a location is created? This would greatly
> enhance interoperability between projects, which imho, is necessary.

I don't think WKT is a very good format to use internally. The WKT 
descriptions of projections are impenetrable to look at and very easy to 
make errors in parsing. They also are not very versatile with regards to 
datum information, in that there is no standard way of specifying a datum 
gridshift file. AIUI it the WKT definitions are specified by the Open GIS 
Consortium, which used to be called the Open GRASS Consortium, but 
obviously has very seriously diverged from GRASS somewhere along the way. 
I've always wondered about the politics of that, but have no idea really.

However, any discussion on the merits of GRASS internal co-ordinate system 
data should be irrelevant to other projects extracting data from GRASS 
locations, because PROJ_INFO/PROJ_UNITS is an *internal* GRASS format, and 
GRASS provides functions to convert those representations to other 
formats. If there is a problem with the tools GRASS provides to extract 
the projection information, then we should investigate these and try to 
make them easier to use - I think this would be the path of least 
resistance.

I guess my point is that it is a reasonable requirement for other software 
to use GRASS libraries to access data in GRASS locations, rather than 
reverse engineering the internal GRASS database formats which can and will 
change in future. But I suppose that is a topic definitely open to 
debate?....

Paul