I'm a GRASS newbie, and have been playing around with aerial photo orthorectification over the last few days. I have used i.ortho.photo to successfully process a frame, working my way through the menu system.
What I would like to know is whether it is possible to batch run the i.ortho.photo command - ie set up the parameters and control points for a number of images but actually rectify them in a job lot that can be left running overnight. I guess another way of phrasing this is to know whether the photo.rectify and associated photo. commands detailed in the reference manual can be called independently of the i.ortho.photo menu. I have tried running 'i.ortho.photo --script' but the output generated does not seem to give any further clues.
Thanks,
Andy
--
Andy Harfoot
GeoData Institute
University of Southampton
Southampton
SO17 1BJ
Tel: +44 (0)23 8059 2719
Fax: +44 (0)23 8059 2849
www.geodata.soton.ac.uk
---------------------------------------
For further information about GeoData's
Training Courses, please visit:
www.gis-train.com
---------------------------------------
On Thu, Oct 16, 2008 at 9:20 AM, Andy Harfoot <ajph@geodata.soton.ac.uk> wrote:
Hi there,
I'm a GRASS newbie, and have been playing around with aerial photo
orthorectification over the last few days. I have used i.ortho.photo to
successfully process a frame, working my way through the menu system.
Great, good to know that it works.
What I would like to know is whether it is possible to batch run the
i.ortho.photo command - ie set up the parameters and control points for a
number of images but actually rectify them in a job lot that can be left
running overnight. I guess another way of phrasing this is to know whether
the photo.rectify and associated photo. commands detailed in the reference
manual can be called independently of the i.ortho.photo menu. I have tried
running 'i.ortho.photo --script' but the output generated does not seem to
give any further clues.
In theory it should be possible since all the menu stuff generates
a couple of ASCII files with reference points and so on. Since the
interactive classical monitor in GRASS 7 is demolished, we do need
some scripted (Python) approach to run the underlying algorithms.
The main program is i.ortho.photo which is just a menu driver for the
following programs:
The general workflow of the i.ortho.photo algorithms is following
Paul R. Wolf, 1983: Elements of Photogrammetry, With Air Photo
Interpretation and Remote Sensing. 562 pages, McGraw Hill Text
2nd edition
(I bought this as used book for a few USD)
> What I would like to know is whether it is possible to batch run the
> i.ortho.photo command - ie set up the parameters and control points
> for a number of images but actually rectify them in a job
> lot that can be left running overnight. I guess another way of phrasing
> this is to know whether the photo.rectify and associated photo.
> commands detailed in the reference manual can be called independently
> of the i.ortho.photo menu.
Markus:
In theory it should be possible since all the menu stuff generates
a couple of ASCII files with reference points and so on.
right, if you look at the end of imagery/i.ortho.photo/menu/menu.c you
can see that each program runs as "$PGM group_name", except i.group
e.g., Andy try running: $GISBASE/etc/photo.rectify group_name
I am not sure, do all the photo.* modules require interaction or does
e.g. photo.rectify just start running once you call it?
Since the interactive classical monitor in GRASS 7 is demolished,
we do need some scripted (Python) approach to run the underlying
algorithms.
I won't be the one to do that, but I will convert the various photo.*
programs to use G_parser().
right, if you look at the end of imagery/i.ortho.photo/menu/menu.c you
can see that each program runs as "$PGM group_name", except i.group
e.g., Andy try running: $GISBASE/etc/photo.rectify group_name
I am not sure, do all the photo.* modules require interaction or does
e.g. photo.rectify just start running once you call it?
Unfortunately photo.rectify is interactive still so I think there's modification to the code required before it can be executed using parameters alone.
I think photo.rectify is the key as all the other elements of the i.ortho.photo sequence generate text files in the group directory to store the parameters, and these could be created independently
Thanks very much for having a look though.
Andy
--
Andy Harfoot
GeoData Institute
University of Southampton
Southampton
SO17 1BJ
Tel: +44 (0)23 8059 2719
Fax: +44 (0)23 8059 2849
www.geodata.soton.ac.uk
---------------------------------------
For further information about GeoData's
Training Courses, please visit:
www.gis-train.com
---------------------------------------
Unfortunately photo.rectify is interactive still so I think there's
modification to the code required before it can be executed using
parameters alone.
in photo.rectify, is it just the setting of the corresponding output map
names which is needed before the calculation begins, or is there more
to fill in past that first screen?
imagery/i.ortho.photo/photo.rectify/ask_files.c has some complication in
it, so I am not sure how easily "i.rectify {-a|input=}" style options
could be added. Probably not as bad as it looks.
I think photo.rectify is the key as all the other elements of the
i.ortho.photo sequence generate text files in the group directory to
store the parameters, and these could be created independently
so that's the only one that takes much computational time right?
I have just done a bit of code cleanup on the i.ortho.photo modules in
6.4svn and fixed a few small bugs. Hopefully I didn't break anything new.
You may wish to update.
devs:
ALL of the i.ortho.photo sub-modules are interactive currently, either
using V_ask lib <esc-enter> text forms and/or an interactive xmon interface,
ala i,points. For GRASS 7 they'll all have to be converted to be non-
interactive before the i.ortho.photo main menu replacement can be rewritten
in wxPython, or the modules will have to be completely replaced to produce
the needed group/ text files (probably not hard for 50% of them ;).
My feeling is that the existing i.ortho.photo code should be removed from
grass7/trunk, as it is V_ask + Xmon from beginning to end.
If the camera specific parts of it could be isolated, we should be able
to link to the existing GCP selection GUI tool, and farm the number
crunching out to i.rectify, using the group/* files as a guide to what the
wxGUI wizard needs to include.
I have now made them all into proper grass modules with G_parser() support.
I doubt I'll do much more on this beyond dealing with the GDAL/line export
symbol build issue. So if someone else feels keen, by all means go for it..
todo: fix up html generation scripts + Makefiles, and move "photo" help
command section back into "imagery" in tools/build_html_index.sh.
Unfortunately photo.rectify is interactive still so I think there's modification to the code required before it can be executed using parameters alone.
in photo.rectify, is it just the setting of the corresponding output map
names which is needed before the calculation begins, or is there more
to fill in past that first screen?
There are two sets of inputs - the output map names, and subsequently, the output region definition, with a choice between using the existing or one calculated using the rectification parameters (with the option to edit it). I guess that this could be simplified to a parameter choosing between using the existing region (which could be set prior to the rectification) or the calculated 'minimal' region, using the existing code.
I think photo.rectify is the key as all the other elements of the i.ortho.photo sequence generate text files in the group directory to store the parameters, and these could be created independently
so that's the only one that takes much computational time right?
Yes.
I hope that helps - I'm currently using the GRASS 6.3 binaries in Cygwin. Is it naive to assume that I can compile your updated i.ortho.photo code and drop it into my 6.3 install?
Cheers,
Andy
--
Andy Harfoot
GeoData Institute
University of Southampton
Southampton
SO17 1BJ
On Thu, Oct 16, 2008 at 6:04 PM, Andy Harfoot <ajph@geodata.soton.ac.uk> wrote:
...
I hope that helps - I'm currently using the GRASS 6.3 binaries in Cygwin. Is
it naive to assume that I can compile your updated i.ortho.photo code and
drop it into my 6.3 install?