[GRASS5] Re: [GRASSLIST:1810] Re: i.ortho.photo on osx

[Markus Neteler]

(cc 'grass5')

Regarding the "boxes" problem in i.ortho.photo results:

Reference:
http://grass.itc.it/pipermail/grassuser/2003-November/010893.html

Above problems should be fixed now (in 5.3-CVS). Reason was
that a DEM of FCELL type was not read properly.
In case of such troubles either update i.ortho.photo or use 
'r.recode' to make the DEM of DCELL type.

If such "boxes" still appear (e.g. with DCELL DEM) there are some
more issues to consider. We have made some more test: The strange 
"boxes" (should be 128x128 pixel) seem to appear in the result 
under certain conditions, when:
- is independent of the operating system
- seem to be independent of DEM in meters/feet 
- resolution of aerial image is much higher than resolution
  of the DEM (e.g 1m vs 10m)
- boxes seem to appear only in mountainous regions with
  high slope. The underlying photo.rectify uses tiles to rectify
  an aerial images. The elevation is taken as a single value for
  all pixels in a tile. With high slope (large elevation range within
  the tile) the deviations are currently large.
  Solution:
  Change 
  src/imagery/i.ortho.photo/photo.rectify/global.h
  from
#define TIE_ROW_DIST 128
#define TIE_COL_DIST 128

#define NROWS 128
#define NCOLS 128
  to
#define TIE_ROW_DIST 32
#define TIE_COL_DIST 32

#define NROWS 32
#define NCOLS 32

  (then recompile). The result will be nice (tested with the above mentioned
   'calico' data set we received from Ian Macmillan).
  Problem: It's much, much slower.

  A good solution would be to have dynamic tile size selection in 
  photo.rectify which takes the elevation/slope (or maybe range vs camera
  height) into account. In plains the tile size might be even larger so
  the the rectification process could be much faster.
  I am unable to implement that and seeking for help (demo locations 
  available on request). Maybe it's not too difficult to implement ...

We have left untouched the tile size 128x128 in CVS. You may test with 
your local installation and hopefully confirm the observations. Then we
can decide if/how to lower it.

Best regards

 Markus Neteler

On Sat, Nov 22, 2003 at 08:18:25PM -0700, Richard Greenwood wrote:
> 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 


-- 
Markus Neteler     <neteler at 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