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,
IanQuoting Richard Greenwood <Rich@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