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

[Dylan Beaudette]

Hi Harri,

It sounds like you are interested in a projection-based
transformation, rather than the affine transformation which
v.transform can apply.

Here are the steps that I would take:

1. collect control points, using a projected coordinate system

custom coordinates
( x,y )

UTM for example
( x', y' )


2. apply affine transform in UTM coordinates

3. inverse project to geographic coordinates, if that is what you really want.


You will need:

1. a new location in UTM
2. import your custom coordinates into that location, ignoring the
fact that the coordinate systems do not match
3. use v.transform


I think that v.transform should issue some kind of error if invoked
within a LL location...


cheers,

Dylan



On 6/12/07, Harri Kiiskinen <harkiisk at utu.fi> wrote:
> 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.
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>