Orthorectification

Orthorectification

Update: Co-authored paper published by Journal of Applied Remote Sensing: Automated imagery orthorectification pilot


Photo left: Raw Film image from USGS archives.

Orthorectification, just a fancy word for processing images taken from the sky to make them geographicaly correct.

If you have used Google Maps or Google Earth you are a consumer of orthorectified images. Or imagery as the industry calls it. If you ever notice an image of the ground that looks sort of distorted, flat or appears to be taken from an angle it could be a image that has not been orthorectified yet.

To simplify it the output of perfect orthorectification should be an image in which you can point to each pixel and determine the true geo coordinate and elevation for that pixel. It tries to generate an image in which the ground of the image appears to be viewed from directly overhead (commonly called nadir). Of course anything sticking up above the ground will typically not appear correctly without a huge amount of additional processing.

The purpose of doing all of the work necessary is to increase accuracy. When all of the imagery is accurate it is possible to then mosaic it all together so there are no seams between images. It is also possible to take imagery taken from different time periods and layer it on top of each other to watch for changes. It enables all sorts of time saving tasks in many industries such as oil, geological work, scientific, electrical transmission, military, civil engineering and more. In the EPA it has been used to discover where pollution is buried by comparing historical images with each other to detect change over time.

Simplified Process Overview

The most accurate form of orthorectification involves sending surveyors in to the field to collect data points called Ground Control Points or GCP. Using GPS units they collect the longitude, latitude and elevation of points on the ground that are visible from overhead images. These are points such as road intersections or visible land marks. The problem is the cost of this option.

Many resort to the next best solution which is to use existing orthorectified images from the past. These are called control imagery.

The next step involves finding the ground control points from the survey or control images and matching them to the same landmarks in the raw images. This used to be a manual process. Someone had to locate these points and then correlate them together. There is now software that can find these points automatically and one can just accept what the software determines or perform a manual review of the points collected.

One must collect 3 GCP per image otherwise the final warping process will produce some strange results. If you ever took trigonometry 3 points are needed to determine the three dimensions of space. With only 2 points one cannot determine the height the photo was taken from and the scale of the photo will be wrong. Most tools require about 8 or so points to be collected and they should be spread throughout the image.

Two tools I have used for automatic GCP collection are PCI Geomatica and Erdas Imagine. I have also come across a module for ossim that does this also but I have not tested it yet. Other tools will perform orthorectification but require you to collect GCP manually.

It appears that PCI Geomatica collects these points by analyzing the high contrast areas where roads cross or the edges of landmarks.
Example of DEM from NASA.

The next part involves a file that contains the elevation model for the area where the image was taken. Often it is a TIFF file that contains pixels of varied shades of grey. Each pixel represents an elevation value by its color and has a geo-coordinate assigned to it. This allows the software to process the image correctly. This is called a Digital Elevation Model or DEM. If the elevation model is not included the process is sometimes called rectification and not orthorectification.

The next stage involves computing a math model called Rational
Polynominal Coefficients (RPCs) using the control image, the digital elevation model, raw image and the ground control points. Many times the camera model is included. This gives the software the distortion values that a camera lens causes.

Now the software takes this math model and starts warping the image. It moves pixels around to make the image as correct as possible. In areas with lots of elevation changes like mountain ranges the finished product will eliminate areas where optical illusions will make a hill look like a depression.

It has been proven that this entire process can be automated but with less accuracy than with an experienced operator. One of the issues is that each sensor or camera source has to be optimized. Each camera or satellite sensor has its own characteristics and the software has to be re-configured to optimize the results. Processing Ikonos images is going to be different from QuickBird. Aerial imagery from aircraft is even more complicated and has less standardization. This is not really a problem if someone has a large amount of imagery from a small handful of sensors.

To see a visual example of orthorectification view this image.

In a future post I can describe the details of the process used on historical aerial imagery.

Resources

http://www.satimagingcorp.com/svc/orthorectification.html
PCI Geomatica
ERDAS
OSSIM - Open Source
Automated imagery orthorectification pilot

LMN Solutions - Find out more about us.

Automated imagery orthorectification pilot

J. Appl. Remote Sens. 3, 33552 (2009)

http://link.aip.org/link/?JARSC4/3/33552/1

The Agile Toolwright

The Agile Toolwright
As a child I remember going camping in our multi-colored VW pop top van with our extended family. No, my family was not part of the whole 60’s thing. It was the late 70’s anyway. My father repaired VW’s in his spare time to flip and this one had not been painted yet. As you will see from this story technical improvisation runs in the family.

On the day we were leaving the van would not start. My dad diagnosed the problem to be the solenoid. (One of those key parts that makes an engine start.) Fortunately we had my Uncle Dwight with us. A man who collected things, all kinds of things, scrap metal, screws, bolts, thermostats, and various pieces of "junk".


His collection was housed in a large shed with an estimated 25,000 cubic feet of storage. It was very organized and collected with a purpose. One portion of it held all of the tools he used to craft art, tools and fix things.


Now Dwight did not just collect these parts he used them. He took them and combined them in ways never seen before. Most often they were used in an urgent manner to fix some major problem like broken well pumps. Dwight seemed to be everyone’s fix up man. If something was impossible to fix or you just did not have money for new parts he was the person to call. Other times he used them to weld fantastic looking sculptures or even tools to accomplish a task.


I went with him to his Red Ford F100 and he pulled up the back of the seat to reveal a carefully organized box of parts. Everything from springs, cables, rope, pulleys to a solenoid were there.


A person with traits like Dwight is most helpful for a software development team. They become even more valuable on an Agile team. The Agile Toolwright is what I like to call them. A Wright is a maker of things as in shipwright. The Toolwright is sometimes called a jack of all trades or toolsmith. This idea and word is based on the term Toolsmith from James Bach. http://www.satisfice.com/presentations/agileauto.pdf and http://www.satisfice.com/blog/archives/15


The Toolwright is able to aid the rest of the developers, testers and even the user representative on the agile team get things done faster and increase velocity. It is someone who has experience at all layers of the software stack and may have positions in most of the life cycle roles, from DBA, tester, developer, help desk, system administrator to help desk. They can quickly research all of the software tools at hand and combine them in strange ways to get a task done all focused around software quality.


The Toolwright ends up building small tools or even an entire continuous integration / testing framework to help remove roadblocks in the way of the developers and testers. Some of the tools they may end up building or integrating together are continuous integration platforms integrated with unit testing, automated testing, code coverage and other extras. They help guide developers in making the application testable. Most of the time is spent helping testers with small applications to help them test faster. Sometimes they even help the users in building interim software to allow the development team to speed the time needed to build the feature correctly for the long term.


The person in this role may not contribute directly in the production code but they have the ability to find the gaps in the process that can be made more efficient. The whole process of developing in an agile fashion goes much better if you have a dedicated Toolwright. Perhaps you do not have a full blown Toolwright on your team but there is no reason it cannot be a shared role between all team members. Try to develop the skills needed and the attitude to help others on your team get their job done quicker.



Well that solenoid was not a VW solenoid; it was a bit too large. Good thing VW engines are not that picky about organ transplants. A little duct tape and bailing wire solved that problem. Watch out, many Toolwrights are not opposed to duct tape solutions. In any case, the van started and got us home.



Now for Dwight, being a toolwright of sorts was not his livelihood but he ended up as the community maintenance man, the ultimate handyman on an extreme budget. Often without cost helped neighbors repair their homes, appliances and cars.


I only hope I can do the same with software and code instead of scraps.

LMN Solutions - Find out more about us.