[GRASS-dev] Vect_get_proj_name() question

[Paul Kelly]

On Wed, 30 May 2007, Markus Neteler wrote:

> On Wed, May 30, 2007 at 08:24:56AM +0200, grass at intevation.de wrote:
>> Author: hamish
>>
>> Update of /grassrepository/grass6/vector/v.info
>> In directory doto:/tmp/cvs-serv1706
>>
>> Modified Files:
>> 	main.c
>> Log Message:
>> try for some formatting improvements. Could probably still use some more.
>> I notice that Vect_get_proj_name() and _zone() are typically unset?!
>
> this is probably a question for Paul:

FWIW I think it is confusing having those functions - we would need to 
keep the zone and proj fields in the vector header I assume for backwards 
compatibility, but perhaps even those functions should be removed so that 
nobody relies on that data for anything important. Certainly I don't think 
they should be extended as that then increases the confusion over where 
projection information can be obtained from.

Do we need better functions for retrieving individual details about the 
co-ordinate system of the current location? If so I would be interested to 
add them or fix things - currently there is G_database_projection_name(), 
G_database_datum_name(), G_database_ellipse_name(), G_database_units_name()
amongst others, the first three of which I don't think are very useful as 
they don't really mean very much without the rest of the PROJ_INFO. But 
they might be useful for display/informative purposes. IMHO those G_* 
functions should always be used for this purpose rather than ones that are 
specific to particular raster/vector maps.

The idea is that a standalone vector or raster map should be 
projection-independent and the eastings and northings contained in there 
should be interpreted relevant to the projection settings 
(PROJ_INFO/PROJ_UNITS) of the location they're in. Storing a few details 
of the projection information in the map header is perhaps an old 
safeguard against displaying a map in a location with the wrong 
projection, dating from when the GRASS projection support was much simpler 
than it is today - now these fields in vector and raster headers simply 
don't hold enough information to characterise a projection. We rely on 
PROJ_INFO for that.

Well that makes sense to me anyway...

Paul