[GRASS-dev] v.transform, wishlist #420

[Harri Kiiskinen]

On Tue, 2007-06-12 at 16:37 +1200, Hamish wrote:
> Harri Kiiskinen wrote:
> > I looked into the matter somewhat deeper, and it turns out not
> > to be as simple as just putting in G_scan_*()-functions. These
> > functions delegate the work to ll_scan(), through G_lat_scan()
> > and G_long_scan(), and ll_scan() normalizes its resulting arguments
> > to the ranges [-180,180] and [-90,90]. The result is, that the
> > coordinates can be given to these functions only if it is supposed
> > to be lat/long-coordinate.
> 
> 
> lib/gis/wind_scan.c
> 
> int G_scan_northing ( const char *buf, double *northing, int projection)
> {
>     if (projection == PROJECTION_LL)
>     {
>         if(G_lat_scan (buf, northing))
>             return 1;
>         if (!scan_double (buf, northing))
>             return 0;
>         return (*northing <= 90.0 && *northing >= -90.0);
>     }
> 
>     return scan_double (buf, northing);
> }
> 
> 
> it only calls G_lat_scan() if the location's projection is lat/lon.
> No need for any extra checks.

That's what I thought when I looked at that code, but the thing is not
so simple, as when using v.transform, there is not way to know, whether
the 'to' or 'from' are coordinates are lat/long or not, because
v.transform is used to transform between different coordinate systems,
and the current location does not necessarily reflect either of these.
An example:

I have a location with a local coordinate system ( x = [6000,9000], y =
[2000,5000] ) for use with an archaeological excavation. To 'fix' this
system to a global system, some points are measured also in lat/long
coordinates. So I have a group of points having coordinates in the
local, metric system and in the global, lat/long system. Just what
v.transform needs to perform the transformation.
	However, if I do the transformation in the original location, where the
vector map is, the lat/long coordinates never go to G_lat_scan, as the
'projection' is not PROJECTION_LL. On the other hand, if I export the
map and import it to the result location and do the transform there, the
metric coordinates will be given to G_lat_scan(), as the 'projection' is
PROJECTION_LL, even though for these points it is not true, and the
resulting coordinates will suffer the normalization to the ranges
mentioned above. I did test this already.
	So I still think, that there needs to be an additional test, either
defined by the user or based on the probability, that ':' in the
coordinate string means a lat/long that needs to be converted to
decimal.

> > In the long run, I'd like to further modify this module so, that the
> > resulting vector could be placed in a different location/mapset, so it
> > could be used to transform vector files from a location based on a
> > local coordinate system to another, 'global' system. 
> 
> could the derived transform parms be used as the +towgs84 7-term
> projection in the new location, then v.proj?

After a quick look at lib/vector/transform, I'd say that not
self-evidently. Someone with good enough knowledge of linear algebra
might be able to figure out, what the different transformation and
rotation coefficients actually mean, and if they could be used in
+towgs84. As the TODO file in that directory says, the "means of
generating the coefficients seems rather odd".
	Then again, v.transform is not really about re-projecting the data,
only about changing the coordinates into a different system (I think
there is a difference?) - usable just for the things its description
says, putting dxf drawings in place, or, in my case, changing vectors
from a very local, small scale coordinate system to something else -
maybe another local system - just by defining some common points. I
think it is nice just because it is simple, but I wouldn't use it for
geographically large areas.

Harri K.