[GRASS-dev] Vect_get_proj_name() question
paul-grass at stjohnspoint.co.uk
Wed May 30 04:11:40 EDT 2007
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:
>> 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...
More information about the grass-dev