Ortho Rectification

[LawrenceFox]

As I review the rectifying and mosaic sections, I'm wondering how these functions fit together.  In my mind images must be ortho rectified before they are mosaicked.  So, I would have expected some text warning users about this?  Or, does the image mosaic data model both rectify and mosaic on the fly?  Also, what if you want to mosaic old aerial photos, how do you input the camera model?  Or, can you input a camera model?

The idea of rectify-before-mosaic is not applicable for full blown photogrammetry however.  Multi-image block adjustment provides the photogrammetric power to render several overlapping photos into an ortho image as long as the images have the required overlap for tie point identification and the camera models are known.  Is ArcMap a fully featured photogrammetric program?  With the discussion in the program documentation of what appears to be statistically based rectification formulas, I don't think so.

I guess the basic question is, does 10.1 provide a photogrammetric model for ortho-rectifying aerial photographs that uses fiducial marks and camera models to remove radial relief displacement or does it use least squares techniques in a more general way?

[VinayViswambharan]

When a collection of images are being managed and consumed using a mosaic dataset and\or an image service, the imagery is processed on-the-fly and dynamically mosaicked. Pixels are sampled only once, with no intermediate products being created. Functions and xforms are chained together to derive a mosaic which is rendered on-the-fly.
We have detailed topics in our online help (and with the installed help) indicating the power of dynamic mosaicking and how you can actually leverage the 30% side and 60% side overlap in case of aerial, and the overlap you have in case of satellite imagery �?? to your benefit. You can sort the imagery (and then mosaic) based on different viewpoints and\or sort it based on different attributes (cloud cover, acquisition date, etc).
ArcGIS is not currently designed to be a fully functional photogrammetric system, although we do work we outputs of 3rd party applications such as Inpho (Match-AT), ISAT, Applanix (EO), and so forth seamlessly well.
For instance, if you do your bundle block adjustment using match-at, the match-at prj file and camera file can be easily ingested into the mosaic dataset. Check the link
http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//009t000001v4000000


Check http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//009t000001v6000000 for help on ingesting imagery acquired by the Applanix dss sensor as well.

As for cameras that are not supported out of the box, we have a generic table type which lets you key in your camera definition parameters, accepts a table with the EO parameters, and pointers to the imagery and elevation source. Resource for the same can be found in http://resources.arcgis.com/gallery/file/image-management/details?entryID=5A7FEB1F-1422-2418-3414-39...

[larryzhang]

Just put personal thoughts here for better communication:

On hands-on experience with LPS/Erdas Imagine plus our limited testing on ArcGIS 10.1 (Beta 2), it is too difficult for current MD data model & infrastructure to handle the traditional up-to-10-cm airphotos 'properly and efficiently' for ortho-rectification, in particular, using classic photogrammetry theory such as bundle adjustment.

However, very optimistic on the future releases to bring us somewhere in that direction with modern airborne camera devices and spaceborne sensors (saying, a mimic or copycat of the traditional bundle adjustment workflow). Of course, as an alternative option for photogrammetry, it may be also good idea easily for camera vendors to customize MD model to support any camera devices, if the objects are open.

As heard, in fact, Lidar processing and data analysis may be already supported within the pre-release of ArcGIS 10.1. Hopefully, airborne Lidar inclusive and processing /analysis good enough, when used in operation.


+++++++++++
Personally, on new MD infrastructure, it should be an IT-enhanced MD. The new MD model should be manageable in operation, saying, only remotely access the raw data folders with 'READ' permission during creation of MD, that is, no any direct 'write' onto the raw data folders. So, it will be different from current MD model (mixed) and also different than LPS (pure 'local').

On more efficient computations, besides, new algorithms with lower computation complexity should be applied somehow, like spline-like least square.