Hi all, anyone out there successfully used i.ortho.photo on max os x (jaguar)?
I have been having bad luck with it. I consistently get a weird tiling effect
with highly distorted images. A good example can be found here.
www.uweb.ucsb.edu/~ian_macmillan/calico.tif
I have a previous post that explains exactly what I did to get this image
(1702). As far as I can tell, I have done everything by the book. Anybody
have any advice?
Thanks a bunch
-ian
On Sat, Nov 15, 2003 at 12:38:05PM -0800, Ian Macmillan wrote:
Hi all, anyone out there successfully used i.ortho.photo on max os x (jaguar)?
I have been having bad luck with it. I consistently get a weird tiling effect
with highly distorted images. A good example can be found here.www.uweb.ucsb.edu/~ian_macmillan/calico.tif
I have a previous post that explains exactly what I did to get this image
(1702). As far as I can tell, I have done everything by the book. Anybody
have any advice?Thanks a bunch
-ian
Ian,
a similar problem we also face (on Linux, so it's a bug in the i.ortho.photo
library).
Some things to check:
- do you have a DEM which covers the area of the target orthophoto,
all at the same resolution?
- what's the elevation difference in that area
(r.univar tells you min and max etc)
We have the impression, that the algorithm is somewhat unstable in regions
with a large elevation range.
Markus Neteler
Markus, thanks for the response. I do have a dem which covers the entire
photo area. It is a little larger in fact, is that a problem? Should I crop it
so that it is the same size as the photo in area? The dem is at 10m
resolution, just like I want the projected orthophoto to be. I made the DEM
with s.surf.rst from a 30m dem, doesn't seem like that should make any
difference from a "normal" dem. In any case the elevation range is only ~540
meters. Is this too much? What is the biggest elevation range that you have
gotten to work?
The r.univar report for the dem is here:
Number of cells: 432276
Minimum: 579.7407226562
Maximum: 1119.2756347656
Range: 539.535
Arithmetic mean: 775.406
Variance: 17639.4
Standard deviation: 132.813
Variation coefficient: 17.1282 %
Thanks a bunch, ian
Quoting Markus Neteler <neteler@itc.it>:
On Sat, Nov 15, 2003 at 12:38:05PM -0800, Ian Macmillan wrote:
> Hi all, anyone out there successfully used i.ortho.photo on max os x
(jaguar)?
> I have been having bad luck with it. I consistently get a weird tiling
effect
> with highly distorted images. A good example can be found here.
>
> www.uweb.ucsb.edu/~ian_macmillan/calico.tif
>
> I have a previous post that explains exactly what I did to get this image
> (1702). As far as I can tell, I have done everything by the book.
Anybody
> have any advice?
>
> Thanks a bunch
>
> -ianIan,
a similar problem we also face (on Linux, so it's a bug in the i.ortho.photo
library).Some things to check:
- do you have a DEM which covers the area of the target orthophoto,
all at the same resolution?
- what's the elevation difference in that area
(r.univar tells you min and max etc)We have the impression, that the algorithm is somewhat unstable in regions
with a large elevation range.Markus Neteler
-----------------------------------------------------
Ian MacMillan
Geological Sciences-UCSB
On Mon, Nov 17, 2003 at 08:13:41AM -0800, Ian Macmillan wrote:
Markus, thanks for the response. I do have a dem which covers the entire
photo area. It is a little larger in fact, is that a problem?
That's perfect. It *should* be larger.
Should I crop it
so that it is the same size as the photo in area? The dem is at 10m
resolution, just like I want the projected orthophoto to be. I made the DEM
with s.surf.rst from a 30m dem, doesn't seem like that should make any
difference from a "normal" dem. In any case the elevation range is only ~540
meters. Is this too much? What is the biggest elevation range that you have
gotten to work?
I cannot tell you right now, have to check first.
The r.univar report for the dem is here:
Number of cells: 432276
Minimum: 579.7407226562
Maximum: 1119.2756347656
Range: 539.535
Arithmetic mean: 775.406
Variance: 17639.4
Standard deviation: 132.813
Variation coefficient: 17.1282 %Thanks a bunch, ian
Markus
>
>Quoting Markus Neteler <neteler@itc.it>:
> On Sat, Nov 15, 2003 at 12:38:05PM -0800, Ian Macmillan wrote:
> > Hi all, anyone out there successfully used i.ortho.photo on max os x
> (jaguar)?
> > I have been having bad luck with it. I consistently get a weird tiling
> effect
> > with highly distorted images. A good example can be found here.
> >
> > www.uweb.ucsb.edu/~ian_macmillan/calico.tif
> >
> > I have a previous post that explains exactly what I did to get this image
> > (1702). As far as I can tell, I have done everything by the book.
> Anybody
> > have any advice?
> >
> > Thanks a bunch
> >
> > -ian
>
> Ian,
>
> a similar problem we also face (on Linux, so it's a bug in the i.ortho.photo
> library).
>
> Some things to check:
> - do you have a DEM which covers the area of the target orthophoto,
> all at the same resolution?
> - what's the elevation difference in that area
> (r.univar tells you min and max etc)
>
> We have the impression, that the algorithm is somewhat unstable in regions
> with a large elevation range.
>
> Markus Neteler
>-----------------------------------------------------
Ian MacMillan
Geological Sciences-UCSB
Ian,
I ran into some unusual results that looked similar to yours. It was a while ago so I forget the exact details, but I got it working correctly by changing the Z units. My foggy recollection is that I supplied a DEM in meters, but my horizontal units were in feet, and the results were highly distorted. And changing everything to feet produced correct results. I you have not solved your problem yet, I would be happy to resurrect my project and see if I can provide a better description.
I do not think an elevation range of 540m should be a problem. I had a project with over 1500ft that came out very nicely.
Both of the projects that I did were on Mandrake Linux, but I doubt that your problems are rooted in OSX.
Best regards,
Rich
At 09:13 AM 11/17/2003, Ian Macmillan wrote:
Markus, thanks for the response. I do have a dem which covers the entire
photo area. It is a little larger in fact, is that a problem? Should I crop it
so that it is the same size as the photo in area? The dem is at 10m
resolution, just like I want the projected orthophoto to be. I made the DEM
with s.surf.rst from a 30m dem, doesn't seem like that should make any
difference from a "normal" dem. In any case the elevation range is only ~540
meters. Is this too much? What is the biggest elevation range that you have
gotten to work?The r.univar report for the dem is here:
Number of cells: 432276
Minimum: 579.7407226562
Maximum: 1119.2756347656
Range: 539.535
Arithmetic mean: 775.406
Variance: 17639.4
Standard deviation: 132.813
Variation coefficient: 17.1282 %Thanks a bunch, ian
>
Quoting Markus Neteler <neteler@itc.it>:
> On Sat, Nov 15, 2003 at 12:38:05PM -0800, Ian Macmillan wrote:
> > Hi all, anyone out there successfully used i.ortho.photo on max os x
> (jaguar)?
> > I have been having bad luck with it. I consistently get a weird tiling
> effect
> > with highly distorted images. A good example can be found here.
> >
> > www.uweb.ucsb.edu/~ian_macmillan/calico.tif
> >
> > I have a previous post that explains exactly what I did to get this image
> > (1702). As far as I can tell, I have done everything by the book.
> Anybody
> > have any advice?
> >
> > Thanks a bunch
> >
> > -ian
>
> Ian,
>
> a similar problem we also face (on Linux, so it's a bug in the i.ortho.photo
> library).
>
> Some things to check:
> - do you have a DEM which covers the area of the target orthophoto,
> all at the same resolution?
> - what's the elevation difference in that area
> (r.univar tells you min and max etc)
>
> We have the impression, that the algorithm is somewhat unstable in regions
> with a large elevation range.
>
> Markus Neteler
>-----------------------------------------------------
Ian MacMillan
Geological Sciences-UCSB
Richard W. Greenwood, PLS
Greenwood Mapping, Inc.
Rich <at> GreenwoodMap <dot> com
(307) 733-0203
http://www.GreenwoodMap.com
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.
Thanks, ian
Quoting Richard Greenwood <Rich@GreenwoodMap.com>:
Ian,
I ran into some unusual results that looked similar to yours. It was a
while ago so I forget the exact details, but I got it working correctly by
changing the Z units. My foggy recollection is that I supplied a DEM in
meters, but my horizontal units were in feet, and the results were highly
distorted. And changing everything to feet produced correct results. I you
have not solved your problem yet, I would be happy to resurrect my project
and see if I can provide a better description.I do not think an elevation range of 540m should be a problem. I had a
project with over 1500ft that came out very nicely.Both of the projects that I did were on Mandrake Linux, but I doubt that
your problems are rooted in OSX.Best regards,
RichAt 09:13 AM 11/17/2003, Ian Macmillan wrote:
>Markus, thanks for the response. I do have a dem which covers the entire
>photo area. It is a little larger in fact, is that a problem? Should I
>crop it
>so that it is the same size as the photo in area? The dem is at 10m
>resolution, just like I want the projected orthophoto to be. I made the
DEM
>with s.surf.rst from a 30m dem, doesn't seem like that should make any
>difference from a "normal" dem. In any case the elevation range is only
~540
>meters. Is this too much? What is the biggest elevation range that you
have
>gotten to work?
>
>The r.univar report for the dem is here:
>Number of cells: 432276
>Minimum: 579.7407226562
>Maximum: 1119.2756347656
>Range: 539.535
>Arithmetic mean: 775.406
>Variance: 17639.4
>Standard deviation: 132.813
>Variation coefficient: 17.1282 %
>
>
>Thanks a bunch, ian
>
>
> >
> >
>
>Quoting Markus Neteler <neteler@itc.it>:
>
> > On Sat, Nov 15, 2003 at 12:38:05PM -0800, Ian Macmillan wrote:
> > > Hi all, anyone out there successfully used i.ortho.photo on max os x
> > (jaguar)?
> > > I have been having bad luck with it. I consistently get a weird
tiling
> > effect
> > > with highly distorted images. A good example can be found here.
> > >
> > > www.uweb.ucsb.edu/~ian_macmillan/calico.tif
> > >
> > > I have a previous post that explains exactly what I did to get this
image
> > > (1702). As far as I can tell, I have done everything by the book.
> > Anybody
> > > have any advice?
> > >
> > > Thanks a bunch
> > >
> > > -ian
> >
> > Ian,
> >
> > a similar problem we also face (on Linux, so it's a bug in the
> i.ortho.photo
> > library).
> >
> > Some things to check:
> > - do you have a DEM which covers the area of the target orthophoto,
> > all at the same resolution?
> > - what's the elevation difference in that area
> > (r.univar tells you min and max etc)
> >
> > We have the impression, that the algorithm is somewhat unstable in
regions
> > with a large elevation range.
> >
> > Markus Neteler
> >
>
>
>-----------------------------------------------------
>Ian MacMillan
>Geological Sciences-UCSBRichard W. Greenwood, PLS
Greenwood Mapping, Inc.
Rich <at> GreenwoodMap <dot> com
(307) 733-0203
http://www.GreenwoodMap.com
-----------------------------------------------------
Ian MacMillan
Geological Sciences-UCSB
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
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. 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?
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@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
-----------------------------------------------------
Ian MacMillan
Geological Sciences-UCSB
On Wed, Nov 19, 2003 at 05:44:38PM -0800, 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. 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?
This is quite crazy! Does anyone have an idea? The code in question
should be
src/imagery/i.ortho.photo/photo.rectify/rectify.c
Does it suggest some precision problems/variable overflows/underflows?
Markus
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
>-----------------------------------------------------
Ian MacMillan
Geological Sciences-UCSB
--
Markus Neteler <neteler@itc.it> http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy
At 09:47 AM 11/20/2003, Markus Neteler wrote:
Our group has recitified 100+ images without problems, in terrible
terrain (200-3500m) with an average error of 6 meters which is
acceptable.
That eliminates one of my theories - that the author of i.ortho.rectify assumed feet.
> However, when I converted the vertical units to feet, the results were correct.
Mhhh. I think that both horizontal and vertical units should be identical.
Yes, so do I! Or some constant needs to be applied if the horizontal and vertical units differ, but I do not see any place in i.ortho.rectify where the vertical units are specified.
> The example in your book uses Spearfish. I don't have Spearfish loaded
> right now, but I am guessing that the elevation model is in feet. Possibly
> I am wrong?No, the spearfish DEM is in meters:
r.info elevation.dem
[...]
| Data Description:
| Elevation above mean sea level in meters for spearfish database
Yes, you are quite right. I loaded Spearfish and worked thru the example in your book and arrived at a satisfactory image rectification.
All of this is to say that I have gotten no closer to identifying the problem. If we rule out an error in the program logic, then it makes me think that the differences are in the definition of the location, but I do not see anything there that specifies a unit for vertical data.
I will keep looking at this, but any pointers would be appreciated.
Best regards,
Rich
Richard W. Greenwood, PLS
Greenwood Mapping, Inc.
Rich <at> GreenwoodMap <dot> com
(307) 733-0203
http://www.GreenwoodMap.com