On Wed, May 30, 2007 at 08:24:56AM +0200, grass@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?!
> 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?!
spearfish e.g.,
bugsites:
Projection: x,y (zone 0)
roads:
Projection: x,y (zone 13)
[should be UTM zone 13]
more importantly new maps are not created correctly,
v.random out=test_rand_2k n=2000
v.info test_rand_2k
Projection: x,y (zone 0)
On Wed, May 30, 2007 at 08:24:56AM +0200, grass@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.
> 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?!
spearfish e.g.,
bugsites:
Projection: x,y (zone 0)
roads:
Projection: x,y (zone 13)
[should be UTM zone 13]
more importantly new maps are not created correctly,
v.random out=test_rand_2k n=2000
v.info test_rand_2k
Projection: x,y (zone 0)
Hamish
My guess is that Radim was thinking of projection on the fly when handling
the proj info per vector map instead of globally as per raster.
Of course it is important to set things correctly.