[GRASS-dev] v.info: projection info wrong

[Hamish]

Markus N wrote:
> (piemonte_utm32_wgs84):/grassdata > v.info
> beni_urbanistici
...
> -->  x,y (zone 0)?
> 
> GRASS 6.4.2svn (piemonte_utm32_wgs84):/grassdata >
> g.region -p
> projection: 1 (UTM)
> zone:       32
> datum:      wgs84
> ellipsoid:  wgs84
> 
> The code chunk is
> 
> v.info/main.c:
>             /* this differs from r.info in that proj info IS taken
> from the map here, not the location settings */
>             /* Vect_get_proj_name() and _zone() are typically unset?! */

(I added that code comment FWIW)

>             if (G_projection() == PROJECTION_UTM)
>                
> sprintf(line, _("        Projection: %s (zone %d)"),
>         Vect_get_proj_name(&Map), Vect_get_zone(&Map));
>             else
> sprintf(line, _("        Projection: %s"),
>         Vect_get_proj_name(&Map));
> 
> Any ideas why this fails?


yes, and the recent change to using the location's info should be reverted.

some history and background on what this is and what it is trying to do:

keeping the UTM zone and grass projection code in the map header is a
failsafe (the method equivalent of a C++ "assert") in case the mapset
or map gets manually mis-copied by a user in an incompatible way. This is
mostly to protect from mixing polar (lat/lon), cartesian, and undefined
XY datasets numbers together. the utm zone is a historic extension of this
from before grass supported "proj type 99: other".

mainly this is implemented in the raster library where libgis complains
if the map's cellhd settings do not match the location's region settings
about what the current map projection is.  see grass6/lib/gis/opencell.c
and $MAPSET/cellhd/ proj: and zone: terms. But also you will see it in
the vector Map_info struct which is saved as part of the vector map.

this safety check is a Good Thing for ensuring data integrity.


the grass6 vector lib also implements such a thing, but apparently Radim
did not get around to fully implementing it. i.e. the problem is with 
v.in.ogr and the vector creating modules (r.to.vect) &/or libvector,
not with v.info.

if you look at spearfish60/PERMANENT/vector/roads/head you'll see it is
used, with:
"ZONE:         13"   (same if you do v.out.ascii format=standard)
and there v.info + utm works as expected. (Zone: 13 instead of 0)


v.info and r.info should reflect metadata info about the MAP, not about
the LOCATION. So that you can debug cases where the two are mismatched,
typically due to a file copied into a place where it shouldn't have been.
Making v.info report the current location's info defeats this debug tool,
misleads the user as to the contents of the map, and is irrelevant info.

That r.info shows info for the current location and not the contents of
the map's cellhd is a bug. (my code comment there from r23738 is to
document the current behaviour, not to say that behaviour is as the
design intends. I now see that it isn't.)


in summary:

v.info should check the embedded zone returned by Vect_get_zone() and
if PROJECTION_UTM and zone==0 should either not print it, or print like
Zone: unknown.

v.in.ogr (if possible), and r.to.vect et al (using the current location's
settings at time of map creation) should be improved to write out that
metadata info into the vector map's 'head' file so it's available for
this check.

r.info should display info about the raster map itself, not about the
current GIS environment. the current way is a bug IMHO.

Map_info->proj likely needs some work to finish taking advantage of it in
the libs & modules, if this "assert" failsafe is to be used with vector
maps. (for my 2c I think it is worth the trouble to keep going with that;
I don't think a .prj file with v.pack is enough to catch all cases, or
robust enough. the mis-copy could just as well be a manual filesystem copy
as a v.pack transportation)


Hamish

ps- FWIW, r.pack and r.unpack, and v.pack and v.unpack, should share
the same source dirs. I am unhappy that r.[un]pack were split up from how
I originally had them, the two modules should be built by a single Makefile
instead of multiple dirs as they are two halves of the same thing, and
their code must always be altered in tandem.