[GRASSLIST:1838] Re: i.ortho.photo on osx

Richard Greenwood Rich at GreenwoodMap.com
Thu Nov 20 08:45:31 EST 2003


Ian,

I think we need to file a bug report on this.

At 06:44 PM 11/19/2003, Ian Macmillan wrote:
>Richard,
>
>So I am amazed, it worked like a charm.  What is more, it also worked much
>faster than using meters (~4 hours processor time with meters, and ~10 minutes
>time with feet).  I am a little confused why this would work though, all you
>are doing is essentially adding vertical exagerration (3.2808 times).  It 
>seems
>like multiplying by any random number would work (e.g. 10, 5, etc.)  Feet 
>makes
>sense only because it is easy to remember.

Not really. You are doing a 3 dimensional adjustment. If one dimension is 
totally wacked then it is harder to reach a solution (there is more error 
to be distributed). The X and Y values are not independent of the Z values 
in this type of adjustment.

If you and I are right, then the original author of this program made an 
assumption that Z values are in feet. GRASS is basically a 2D GIS and this 
assumption was probably made a while ago and then forgotten.

If there are GRASS users that have successfully rectified imagery with 
i.ortho.photo using meters would they please let us know. This would help 
us to confirm or disprove the assumptions that Ian and I are coming up with.


>  This goes against an earlier post that said big elevation differences 
> don't work that well.  Any ideas from the gurus why this would happen?

I missed that post, but you may have taken it out of context. Some 
people/programs do not rectify against a DEM because there are other 
sources of distortion that are much more significant that elevation.

>My next step is to make the DEM file in feet first, then use that as the 
>target
>elevation file originally, and go from there.  This would save the tedious 
>step
>of having to convert everything into feet.
>
>The only addition I would add to your directions are to make sure that you
>change the target elevation file to the new dem_feet file (obviously).
>
>Thanks a lot for you help,
>Ian
>
>
>Quoting Richard Greenwood <Rich at GreenwoodMap.com>:
>
> > At 10:04 AM 11/18/2003, you wrote:
> > >Richard, thanks for your response. If you had a similar experience, I am
> > >pretty
> > >curious to know what happened.  I am not sure that I have a feet to meters
> > >problem though.  I am projecting from an XY location into an UTM
> > projection.
> > >The dem elevation units are in meters.  I projected my dem from a lat-long
> > >location, however the elevation units were meters in that too.  If it 
> isn't
> > >much trouble, I would be curious to see what your case is.
> >
> > I am by no means an expert with i.ortho.photo. I have only done two
> > projects with it. But I did just revisit the project that gave me some
> > difficulty. Initially I was in UTM meters, with a DEM in meters and 
> control
> > points in meters, but I was getting no joy. When I converted the DEM and
> > the control points to feet it worked correctly. The project fell by the
> > wayside, and I had forgotten about it until I read your post.
> >
> > At the risk of sending you on a wild goose chase, you can test my premise
> > fairly easily:
> >    1. convert your DEM to feet with r.mapcalc dem_feet = dem * 3.2808
> >    2. convert your CONTROL_POINTS file to feet. (save a copy of your
> > existing file then convert the elev field for each row to feet.
> > Everything else can stay in meters.
> >
> > Please keep me posted if you choose to try this.
> >
> > Rich
> >


Richard W. Greenwood, PLS
Greenwood Mapping, Inc.
Rich <at> GreenwoodMap <dot> com
(307) 733-0203
http://www.GreenwoodMap.com  




More information about the grass-user mailing list