On Wed, 30 May 2007, Markus Neteler wrote:

On Wed, May 30, 2007 at 08:24:56AM +0200, [EMAIL PROTECTED] 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

_______________________________________________
grass-dev mailing list
[email protected]
http://grass.itc.it/mailman/listinfo/grass-dev

Reply via email to