As the saying goes, to all good things must come an end. And sadly, we say goodbye this month to our regular series, the Geospatial Frequently Asked Question (G-FAQ); but fear not my two dedicated readers (ha!), we are replacing the G-FAQ with a new series called the Geospatial Tip of the Month (GTM). The GTM will have a similar approach in that it will address geospatial, GIS, imagery, remote sensing, etc. topics, however the format will be more condensed with a focus on videos where appropriate. I will also provide more ‘in-line’ links for our readers to delve deeper into side topics that arise as we explore the broad theme in each GTM. Oh and there is a small too slim chance that the GTM will not be monthly but it is my goal to keep them as regular as possible. So without further ado, let’s jump headlong into this month’s GTM.

Loading Metadata into ArcGIS with IMD Files

While there are multiple satellite imagery sources on the market, one of the most popular is DigitalGlobe. Operating a six satellite constellation including, GeoEye-1, IKONOS, QuickBird and WorldView 1/2/3, DigitalGlobe is a leading provider of high-resolution imagery. With their data products comes a standardized text file, ending in the extension .IMD, which contains metadata about each of the imagery scenes delivered to a client. If you open one of these IMD files, you will find a wealthy of information about the collection geometry and times, processing kernels and much more. For a complete list of the metadata included in DigitalGlobe’s IMD files, please refer to this detailed PDF.

In the video that accompanies this GTM, we will walk you through the steps of loading an IMD to check out the metadata that it loads in Esri’s ArcGIS. This metadata can be important for imagery users as they being to work with and analyze their DigitalGlobe datasets. From what we can tell, ArcGIS uses the metadata contained in these IMD files to improve mosaicking of multiple imagery datasets and very likely in pansharpening (though I cannot find evidence to back up this assumption anywhere). Admittedly, we use ArcGIS to work with vector datasets most commonly as it is not as powerful as Exelis’ ENVI or PCI Geomatics with regards to raster processing. So it is impossible for me to test how this metadata impacts mosaicking (and more) as we lack the licenses to do this. Here is a detailed handling of orthorecification and mosaicking of raster files using IMD metadata with ArcGIS.

A few additional points here on metadata before we move on to loading tiled imagery in ArcGIS:

• The information provided by Esri suggests that it is possible to load metadata with a wide variety of satellites, however we tested this on our end and had no luck. It is likely that you need to load this metadata info in the mosaicking process hence I could not find a way to do so.
• While IMD files are specific to DigitalGlobe sensors, keep in mind that IKONOS and GeoEye-1 were owned by GeoEye in the past. As such, if you have legacy files from these satellites, they will not contain IMD files to load metadata in ArcGIS.
• Every imaging company that owns a satellite provides metadata in their own custom format. Here is detailed information about the metadata contained with Pléiades 1 imagery, our other favorite high-resolution satellite.
• And finally, my use of the expression, imagery metadata, should not be confused with US government FGDC metadata standards. You can find out more about FGDC imagery metadata standards here.

Loading Tiled DigitalGlobe Imagery Products in ArcGIS

If you have ever ordered a large imagery dataset from DigitalGlobe, you likely found it divided into multiple tiles referred to as R1C1, R1C2, R2C1, etc. This is done for several reasons. First, the traditional GeoTIFF format has a file size limit of 4 gigabytes (GB) so tiling a large imagery order gets around this size limit. And second, loading one huge, high-resolution imagery file can take some time and it also can cause ArcGIS to run very slowly as you zoom and pan across the data; tiling helps to speed up these processes. That said, tiling can be annoying, especially if you have a huge number of tiles to load and work with in ArcGIS.

DigitalGlobe delivers a .TIL file with all imagery products that have been tiled out. This file is easy to load in ArcGIS as we will show you in the video here. Note that none of the other imagery companies currently provide such a file but I would not be surprised if that were to change in the future.

As a quick side note to this discussion, on the Esri website referenced above, it mentions that an IMD file should also load a tiled DigitalGlobe imagery product with the associated metadata. Unfortunately, I tested a wide variety of DigitalGlobe datasets and I found no way to load a tiled product with one button push as well as the metadata–perhaps it is a version issue on my end or a misstatement by Esri.

Do you have an idea for a future GTM? If so, let me know by email at brock@apollomapping.com.

Brock Adam McCarty
Map Wizard
(720) 470-7988
brock@apollomapping.com

Have you ever loaded two files into ArcGIS with different projections yet they still lined up? I am guessing all of you will say yes as this is one of ArcGIS’ best features, albeit it rather seamless and hidden. The automated feature that lines up these various spatial layers is called, projecting (or re-projecting) on the fly, and will be the focus of this month’s Geospatial Frequently Asked Question (G-FAQ). Similar to the last few months of the G-FAQ, I will start off with a short explanation of the topic followed by a tutorial video.

In this G-FAQ, we will focus on answering the following set of core questions:

What is projecting on the fly and how does it line up my spatial layers? When might projecting on the fly fail? Are there any special considerations to working with datasets that have been projected on the fly?

In the distant past, ArcGIS did not have the ability to line up spatial layers, including vectors and rasters, that were loaded if their projections differed. When I say that spatial layers with different projections would not line up, here is an example. If you loaded a color raster image file with a WGS84 datum and geographic coordinates; then loaded a parcel layer from the same location with a WGS84 datum but UTM coordinates, the vector file would not appear over top the raster imagery. Rather, the two files would look to occupy different geographic spaces even though they are indeed from the same location. While I am not 100% sure when on the fly projections were added, they have been a part of the software since version 9.0 at least.

So then, projecting data on the fly is a feature that is rather seamlessly done by ArcGIS where by the data frame of your current session assumes the projection of the first file you load. In the example above then, since we loaded the raster imagery first, the data frame would assume a geographic WGS84 projection. And then when the second file is loaded, it is automatically re-projected from UTM WGS84 to match the Geographic WGS84 projection of the data frame and the first spatial file. This on the fly projection continues as more and more spatial layers are loaded into the same ArcGIS session. It is important to note that files transformed on the fly are done so in memory only so that the original file remains unaffected.

On the fly projections only work when each of the spatial layers has metadata defining the datum and coordinate system (i.e. its projection, see this past GFAQ for more details on this topic). Returning to the example above, if the first layer we loaded, i.e. the raster, was not projected (see the link above to determine if a dataset is projected), then the data frame would not assume any projection. And similarly, if the second spatial file we loaded was not projected but the first layer was, then on the fly projection would fail and the layers would not line up.

While on the fly projections are a huge time saver, there are some points that need to be considered so as to avoid errors:

• Loading projected layers in a different order can cause slightly different alignment (or misalignment) as well as change the look and feel of the session as the data frame assumes the first projection and then reprojects subsequent layers to this.
• In some cases, ArcGIS will make assumptions about a spatial layer even if it is missing projection metadata. This is often the case with geographic coordinates whereby Arc will assume a WGS84 datum which may or may not be correct.
• If a subsequent file is loaded with a datum that does not match that of the data frame, ArcGIS will throw up a warning that a geographic transformation (see this GFAQ for more details on transformations) is required and will typically choose the best option. It is important to note that the mathematics required for this geographic transformation are only an approximation for processing speed. If a precise transformation is required, you will need to use the toolbox functions Project (for vectors) or Project Raster to change the actual source file.
• You can check the Data Frame properties to determine what on the fly projection has been set by right-clicking on Layers in the Table of Contents.
• On the fly projections should only be used for visual display of data. You should never make area or distance calculations off of on the fly reprojected data given the mathematical approximations stated above. If you need to make these calculations, you should reproject all of the source files into the same projection with the toolbox functions mentioned above.

Now that we have set the stage for on the fly projections, it is time to spend a few minutes on a visual review of this topic in the video tutorial you will find here.

Do you have an idea for a future G-FAQ? If so, let me know by email at brock@apollomapping.com.

Find Out More About This Topic Here

• Harvard University–Why Don’t My Layers Line Up?
• Hunter College–What is a Datum Transformation?
• Rice University–Introduction to Coordinate Systems and Projections
• Texas A&M University–Lab Assignment 04: Map Projections

Brock Adam McCarty
Map Wizard
(720) 470-7988
brock@apollomapping.com

Continuing with the theme of ArcGIS lessons started in December’s Geospatial Frequently Asked Question (G-FAQ), this month we look at the steps required to calculate the area of a polygon shapefile. In this G-FAQ, we cover some of theory behind calculating areas in ArcGIS and then also offer a short video showing you the exact steps required to complete the calculation.

Specifically, this G-FAQ will address the following set of core questions:

What is the easiest way to calculate the area of a polygon file in ArcGIS 10.x? What projection does the data need to be in to support this calculation? What field type should I use for area calculations?

Before you watch the short video accompanying this G-FAQ, take a few moments to read through some of the theory behind area calculations in ArcGIS. We have ordered the information below to mimic the steps taken in the video.

Choosing the Correct Projection

In order to complete an area calculation for a polygon shapefile, it needs to be in a projected coordinate system as opposed to geographic, as a geographic system projects data on to a round surface so it is impossible to accurately measure distances, areas, etc. Data in a projected coordinate system is displayed as if sitting on a flat plane so it is now possible to accurately calculate distances, areas, etc.

If you are working with polygons in a small area, you can chose a local projected coordinate system that you commonly work in, for instance UTM. However, for area calculations that include polygons spread over a large region, you will need to choose an equal-area, global projected coordinate system. A projected coordinate system can prevent distortion in one spatial dimension but will then always distort in another. Projected systems can control for: equal area, equal distances, equal angles, direction and scale; but they cannot control for all at once.

My equal-area, global projection of choice is: Cylindrical Equal Area (World). It models the world with perpendicular latitude and longitude lines. Longitudes are spaced equally while latitudes are unequally spaced to account for the shrinking volume of our global as you move to the poles. A WGS84 datum is used as it is the mostly widely accepted global datum. There are other equal area projections you could choose, for instance you can shift the latitude lines used for baseline calculations farther north to de-emphasize area miscalculations in high latitudes.

Choosing the Correct Field Type

Once you have re-projected your data into the equal-area system of your choice, it is time to add a field to your attribute table to hold the area calculations. We will walk you through the exact steps of doing this in the short video that accompanies this G-FAQ, but for now a bit of theory behind the field types you can add. For numeric values, you are able to create these types of fields (or columns):

• Short Integer–numbers without decimal places between -32,768 and 32,767
• Long Integer – numbers without decimal places but of any length or number of digits
• Float–numbers with decimals with less than 7 digits total (including decimal places)
• Double – numbers with decimals and no length limit

For each of these four field types, you are also able to define the precision and scale for the new column. Precision equals the total number of digits you can store and is an option for all four field types. Scale is the total number of decimal places and so is only an option for float and double field types.

When I calculate polygon areas in Arc, I typically choose a double field with “20” for precision and “10” for scale.

Comparison of Area Calculations With Different Equal-Area Projections

We have one final item to cover quickly before you check out the short video here. To show you how close equal area projections are to each other, I projected the same shapefile into three different systems. The polygon file I used spanned the globe and contained 176,987 individual polygons. Here is the total area calculated by each of the three equal-area projections:

• South Pole Lambert Azimuthal Equal Area–256,117,937.745012 square kilometers (sq km)
• Sphere Cylindrical Equal Area–255,623,570.713166 sq km
• World Cylindrical Equal Area  – 256,123,154.208427 sq km

To put these figures a different way, if you set the total area calculated by World Cylindrical Equal Area as the ‘true value’ then here  is how close the other two projections come:

• South Pole Lambert Azimuthal Equal Area–99.998% of the true value
• Sphere Cylindrical Equal Area–99.805% of the true value

So then, what you see from these comparisons is that shifting the baseline latitude line north or south has little impact on the final area calculations as the South Pole equal area projection was very close to our true value. The bigger impact on these calculations is the datum used in the re-projection as Sphere Cylindrical Equal Area is much farther off since it uses a spherical representation of the globe; and not the most widely-regarded (and accurate) global datum, WGS84, used in the other two projections.

Do you have an idea for a future G-FAQ? If so, let me know by email at brock@apollomapping.com.

Find Out More About This Topic Here

• State University of New York, Syracuse–About XY Domain & Precision in ArcGIS
• University of California, Santa Barbara–Lecture 5
• University of Colorado–Map Projection Overview
• University of Maine–Coordinate Systems and Map Projections for GIS
• University of Notre Dame–Creating Vector Data in ArcGIS
• University of Washington–Projections and Coordinate Systems

Brock Adam McCarty
Map Wizard
(720) 470-7988
brock@apollomapping.com

Sometimes a picture is worth a thousand words, and that is especially the case if you have ever read my verbose Geospatial Frequently Asked Question (G-FAQ) series, haha! So this month, I break from tradition with a video tutorial as the focus of this G-FAQ on color balancing rasters (or imagery) in ArcGIS 10.x. This is a topic that could take hours to cover, so this month I focus on one specific issue I have noticed with ArcGIS 10: the automatic color balance it applies to rasters.

Specifically, this G-FAQ will address this set of questions:

How do I know if ArcGIS applied a stretch to my imagery? How do I turn this stretch off? How can I make the stretch ArcGIS automatically applies look better?

Before you jump into the video posted with this G-FAQ, let me spend a bit of time introducing this topic. When you snap a picture on your cell phone, there is an involved process on the backend which takes the raw image and makes the colors look as ideal and realistic as possible. And as many of you have found out, this automated process is not always ideal–hence cell phone makers have given us the power to edit the images, for instance with the Auto-Enhance option on the iPhone. The process I just described is often referred to as: color balancing, histogram stretching or color enhancement (in the world of remote sensing and/or GIS that is).

Color imagery, including a cell phone photo, is created by combining the blue, green and red reflectance values from a surface. When speaking of satellite and aerial imagery specifically, these blue, green and red surface reflectance values can be reported in either 8 or 16-bit depth. While we do not have the time to cover this topic in full (see our January 2013 G-FAQ for a more detailed handling of bit depth), bit depth refers to the number of blue, green and red shades that are possible in an image. In 8-bit depth, there are 256 shades possible and then with 16-bit there are 65,536 shades. However, a computer monitor cannot read 16-bit depth images, so they must be converted to 8-bit depth to be visible. Before a 16-bit image is converted to 8-bit depth, it will look like an all black tile. Once converted to an 8-bit image (or even if you started with an 8-bit image), you should see colors in a program like ArcGIS when you load a raster but they might not be ideal. And so that is what color balancing is for!

Okay, now that we have introduced the topic, it is time to move on to the tutorial. In this video, I will load both 8 and 16-bit depth satellite images into ArcGIS 10.1 to show our readers what happens and then offer a few color balancing tips.

Do you have an idea for a future G-FAQ? If so, let me know by email at brock@apollomapping.com.

Find Out More About This Topic Here

• Esri–Raster Stretch Functions
• Fort Lewis College–Digital Image Analysis Techniques III–Image Enhancement
• University of California, Irvine–How to Stretch Image Pixel Values

Brock Adam McCarty
Map Wizard
(720) 470-7988
brock@apollomapping.com

In last month’s edition of the Geospatial Frequently Asked Question (G-FAQ), we started our discussion on ground control points (GCPs) and their relationship to orthorectification. Specifically, our focus was on determine the number of GCPs required to create an accurate orthoimage and then selecting the locations for these points. In this edition of the G-FAQ, we conclude the discussion of GCPs by offering tips on collecting them in the field, recording metadata about each and then applying them to your orthoimage.

As a quick reminder, our focus in this two-part G-FAQ edition is on these questions:

What are ground control points and how do they improve the accuracy of high resolution satellite imagery? How do I decide on the number required and the locations of these ground control points? What best practices should I follow in the field when collecting ground control points?

In the October edition of the G-FAQ, we learned that ground control points are locations on the planet with a precisely known X, Y and Z position. When these control points are photo identifiable in high resolution imagery, they can be used to improve the data’s accuracy through orthorectification. Starting in August, we discussed the basics (and some of the nuances) of orthorectification, you can read more about the process here. In last month’s G-FAQ, I introduced an equation to help you determine the number of GCPs required for orthorectification and also looked at the ideal distribution of these points. This month, we pick up the discussion with a focus on collecting GCPs and then applying them to your raw high-resolution imagery.

A series of images and photos that are good examples of the overhead imagery view and then on-the-ground photo views that should be recorded for each GCP surveyed. This is a NOAA control point collected around Cleburne Municipal Airport, Texas. The surveyor who recorded this GCP took three photos of the location from the north, south and west to illustrate the location of the point. And then on the three images, you can see a label added that uses the unique GCP ID number as well as indicates the direction the photo was taken (i.e. N = north; S = south; etc.). There is also an accompanying screengrab of the high resolution imagery with the location of the GCP indicated. (Photos and Map Credit: NOAA)

Step 3–Collecting Ground Control Points in the Field

Now that you have determined the number of GCPs required and their general locations, it is time to head out into the field to collect this data! Here is a check list to be sure you are ready for your trip out to the field and then some advice on what to do once you get there.

• First things first, it is time to pack your gear for the field. Here are some items you will want to be sure are included in your backpack:(1)  A differential GPS unit or conventional surveying equipment. Whatever you chose, be sure it can achieve accuracies equal to half the imagery’s pixel size or better.

  (2)  A tripod for the GPS unit (or surveying equipment) with a precisely measured height to the bottom of the GPS while it is locked on the tripod. Be sure to record this height in a safe place as you will need the information later.

  (3)  A camera to take photos of the GPS-tripod in position, collecting control data.

  (4)  Back up batteries or alternative power sources for the GPS unit and camera.

  (5)  A laptop with the screengrabs of the approximate GCPs locations loaded on it as well as a copy of the raw imagery files.

  (6)  A premade document on the laptop to record the position information (i.e. X, Y and Z coordinates) reported by the GPS unit. We will discuss the format for this positional information in more depth below.

• Now let’s move to some tips for working in the field to collect GCPs. First and foremost, whatever you do, your safety is the number one concern! If you have selected GCPs that are on private grounds, be sure to request permission before you enter their lands. And if you have selected locations for GCPs that are unsafe when you get to the field, chose an alternate location that is safe (see some tips below on changing the location of GCP sites).
• When you have decided on the final location for each of your GCPs, set your tripod and GPS unit in place and let it get a lock on the number of satellites it needs to achieve the accuracy you desire. While you are waiting on the GPS unit to lock its position in, you will need to take at least two photos of each GCP. And be sure to take photos of the GPS unit-tripod from different angles. These photos will be crucial when you get back into your office and try to relate each GCP to the exact pixel it represents in your imagery.
• If you do change GCP locations in the field, it is a good idea to mark an imagery screengrab with the new position. If the new locations are not on the original set of screengrabs you made, create a new screengrab(s) and mark the new GCP site(s).
• In order to keep your GCPs organized, it is a good idea to create a spreadsheet to record the metadata on each control point you survey. Here are the items we suggest you add to the spreadsheet:(1)  The model and number of the tripod, GPS unit and/or surveying equipment used.

  (2)  A point identification number.

  (3)  The X, Y and Z coordinates of the point.

  (4)  The projection (i.e. datum, coordinate system and units) used to survey the GCP.

  (5)  The estimated error or XYZ covariance matrix for each point.

  (6)  Written description of the general location of each point.

  (7)  Additional notes including details on how photos and imagery screengrabs of each point are named.

  If you would like to use a spreadsheet I created, you can download it here.

Step 4–Applying Your Ground Control Points to Imagery

Now that you have collected your set of GCPs, it is time to get back into the office and apply them in the orthorectification process. In short, what you need to do is locate the exact pixel that each of your GCPs relates to–that is why the photos you took in the field are so important. As you find this exact pixel and apply GCPs, be sure look at the RMS error (sometimes called residuals) of each point you add as one bad point could degrade the accuracy of the final product. Keep in mind that residuals are computed on a global best fit basis so a point with a high residual might not actually be bad. It might just be isolated as isolated GCPs often have higher residuals than will clustered GCPs. If possible, having a final residual value smaller than your pixel size is the goal. And one final word to the wise with regards to GCPs, if you can, be sure to leave out several points to test the accuracy of the final orthoimage you have created.

Well, that brings us to the end of our discussion of orthorectification and ground control points. Hopefully you learned a bit along the way in this four part discussion!

Do you have an idea for a future G-FAQ? If so, let me know by email at brock@apollomapping.com.

Find Out More About This Topic Here

• Michigan Technological University–Photogrammetric Control Survey
• Penn State University–Land Surveying and GPS
• Texas A&M University–Remote Sensing in Geosciences
• University of Arkansas–Control Point Documentation
• Western Oregon University–Image Registration

Brock Adam McCarty
Map Wizard
(720) 470-7988
brock@apollomapping.com

In our last two editions of the Geospatial Frequently Asked Question (G-FAQ), we focused on the basics of positional accuracy with regards to high resolution satellite imagery, and specifically on orthorectification. In these G-FAQs, we learned that in order to orthorectify an imagery to the highest accuracy possible, an elevation model, RPCs or a camera model and ground control points (GCPs) are required. In this two part G-FAQ series then, we expand upon the topic of ground control points with a discussion of best practices for selecting their locations and surveying them in the field.

Specifically, our focus in this two-part G-FAQ edition will be on these questions:

What are ground control points and how do they improve the accuracy of high resolution satellite imagery? How do I decide on the number required and the locations of these ground control points? What best practices should I follow in the field when collecting ground control points?

Before we being this G-FAQ, let me first frame the discussion a bit. As in the G-FAQ editions on orthorectification, our focus here will be on high resolution satellite imagery as in order to utilize GCPs, they must be clearly visible in the imagery source. In August and September, we learned that orthorectification is the process of taking loosely referenced imagery and tying it to its ‘correct location’ on the planet. In order to complete this process, an elevation model (i.e. a DEM) and RPCs or a camera model are required. However, to have a stated accuracy, GCPs are required whereby it is possible to measure the distance of a known feature in the orthorectified imagery, such as the corner of a sidewalk, from its true location on the planet. With this in mind, let’s jump head long into this discussion of GCPs, their importance, selecting appropriate locations and collecting them (safely) in the field.

Basics of Ground Control Points (GCPs)

An example of a benchmark established by the US Coast and Geodetic Survey. These metallic benchmarks are typically several inches across so they are not photo identifiable in high resolution satellite imagery. In this example, the point in the center of the triangle is where this benchmark was surveyed with a differential GPS unit. (Photo Credit: Mountain Empire Community College)

Ground control points are locations on the surface of our planet with a known X/Y (e.g. latitude and longitude) and Z (e.g. height above mean sea level in meters). In order to use GCPs in the orthorectification of high resolution satellite imagery, they must be photo identifiable–meaning that the points must be clearly visible in the images you are working with. Here in the United States, there is a series of control monuments (also called benchmarks) established across the country, usually demarcated by small bronze or silver plaques. And while these monuments are extremely accurate, they cannot be seen in high resolution satellite imagery so they are not appropriate for use in orthorectification.

In order to use GCPs in the orthorectification process, they need to be extremely accurate. You cannot collect them with a low-priced handheld global positioning system (GPS) unit or with your smart phone. What is required is a survey-grade GPS unit which is often referred to as a differential GPS unit. These units work by locking on to multiple GPS satellites in space that then triangulate your position on the ground. The longer you wait, the more accurate your position will be calculated as more satellites lock onto the unit. The position of each GPS satellite is then verified and corrected by a series of ground stations that monitor their orbit, velocity and direction of movement.

Returning to the visual analogy used to describe orthorectification in our last G-FAQ series, if you consider imagery a balloon and a DEM as an accurate representation of the shape of the planet’s surface, then GCPs are the tie points used to attach the balloon to its correct location over the DEM. By using a network of evenly distributed GCPs that tie your balloon to the DEM, you can stretch the balloon over the shape of our planet and move it to its correct location with regards to its XY position. It follows then that the accuracy achieved by orthorectification is limited by the positional accuracy of the GCPs and the ‘trueness’ of the representation of the Earth’s topography (i.e. the DEM).

Step 1–Determining the Number of Ground Control Points

The first step in obtaining GCPs for use in orthorectification is determining the number of control required for your area of interest. In general, we tell clients to collect at least 10 GCPs as that way you will have extra control to toss out if it is of low quality and/or use for accuracy testing; and if you can collect more than 10 points, by all means please do! More GCPs are required: (1) as your area of interest grows in size; (2) in areas with lots of terrain change; and (3) if you have multiple overlapping images to orthorectify. Here is an equation you can use to help determine the number of GCPs to collect:

Number of Control = 10 + (Area Covered in Square Kilometers / 25) + (2 x Number of Overlapping Scene Edges)

So if you had a polygon that is 150 sq km with two scenes that overlaps at a single edge, then you would want to collected at least 18 GCPs. Please keep in mind this equation is just a rule of thumb and is definitely not accurate in all cases, for example if the area is very mountainous.

Step 2–Selecting the Locations of Ground Control Points

Now that you have determined the number of GCPs required for your dataset(s), it is time to pick out good locations to survey in the field. Here are some general tips to follow when selecting the locations of GCPs:

1. Spread out your points as much as possible across the imagery as clustering GCPs results in lower accuracy as you move away from the cluster.
2. Select at least two points per edge (if possible) where various images overlap.
3. Be sure to select points that are in high, medium and low elevation areas by using a free DEM such as ASTER GDEM, USGS NED or SRTM as a guide.
4. Choose features that are stationary and unlikely to move. Also choose flat features when possible as they have no lien in the imagery so their locations can be determined more accurately.
5. Features with a high contrast between them and surrounding grounds will be the easiest to locate accurately in your imagery.
6. Select features for GCPs locations that are big enough to easily see in your imagery but also small enough so that you can pinpoint the exact location down to a single pixel.

With a general sense of the locations to look for, the next step is to scan your high resolution imagery, pick out the features you will survey in the field and then take both a screengrab of the locations as well as a general latitude and longitude. The screengrabs and coordinates will help to orient you when in the field. Now, here are two lists of suggested locations for GCPs in both urban and rural areas:

Examples of good (in green) and bad (in red) locations for ground control points. Bad Example 1–in dense urban areas, sides of buildings are poor choices for GCPs as it is hard to determine the exact pixel that represents the base of the building. Bad Examples 2 & 3–similar to the lien you see in buildings, you also see this effect in electrical towers (example 2) and poles (example 3). Good Example 1–this parking lots seems to be rather empty even during working hours so access should be relatively easy; and the intersection of the two white parking stripes can be located to the pixel. Good Example 2–the corner formed by the grass and sidewalk is very angular so you can easily locate the pixel for the point. Good Example 3–and similarly, the corner formed by the parking lot and grass is distinct. 40-centimeter color image collected by GeoEye-1 on August 25, 2011 over Denver, Colorado. (Image Courtesy: DigitalGlobe)

More examples of good (in green) and bad (in red) locations for ground control points in urban areas. Bad Example 1–while the edge of a sidewalk is distinct, without using an intersection of them, it is impossible to determine the exact pixel you are surveying in the field. Bad Example 2–while the end of this centerline stripe is distinct, it would be unsafe to put your surveying equipment here for an extended period of time. Bad Example 3–this building edge is obscured by a dark shadow making it even more difficult to find the pixel that represents its base. Good Example 1–this intersection of two sidewalks is distinct to the pixel level and access should not be too restrictive. Good Example 2–school grounds can usually be entered after hours and this tennis court line can be identified to the pixel. Good Example 3–the sharp point formed by the dirt and sidewalk can be related to a single pixel. 40-centimeter color image collected by GeoEye-1 on August 25, 2011 over Denver, Colorado. (Image Courtesy: DigitalGlobe)

Urban GCP Suggestions

• Corners and intersections of sidewalks
• Corners of pavement and parking lots
• Parking space lines and particularly the intersection of these lines
• Painted white and yellow center lines of roads (though these can have safety issues when surveying them in the field so use sparingly)
• Choice points at local high spots that might not have been apparent in the free DEM analyzed before you went into the field
• Avoid building corners if possible as their lien in imagery can obscure where the building exactly hits the ground

Rural GCP Suggestions

As you can imagine, finding good control in rural areas can be challenging, especially if it is very remote. Given this, orthorectified images in rural locations tend to be less accurate than those from urban areas.

• Edge of bridges where they meet a road surface
• Sides of roads and paths where they curve and/or intersect with other roads and paths
• Bottoms of telephone poles and/or electrical towers
• Fences when they can be seen in the imagery (it is often the shadow you see as opposed to the fence posts and rails)
• Livestock pens, though these tend to change locations more so than other rural features
• Road and stream intersections
• Stream curves or intersections with other streams
• Distinctly colored or shaped rocks
• Small shrubs
• Distinct clearings in trees

When all else fails, if your location is so rural that there is no possibility of finding appropriate locations for GCPs, then you can establish control in the field with painted wooden/plastic panels. The main issue with this technique is that you need to put these panels in the field before the imagery is collected so it is not an option for many projects. If you do want to put your own panels in the field for ground control, I suggest using a white or beige surface with a black X painted on it. The panels should be at least five times the pixel size so they will be obvious in your high resolution imagery. Place the panels in flat, open areas with no trees and away from roads so there is less risk of vandalism. You will want to obtain permission to put these panels on private lands.

In our next G-FAQ edition, we will continue this conversation on GCPs with a focus on surveying the points in the field and using them to orthorectify your imagery.

Do you have an idea for a future G-FAQ? If so, let me know by email at brock@apollomapping.com.

Find Out More About This Topic Here

• Michigan Technological University–Photogrammetric Control Survey
• Penn State University–Land Surveying and GPS
• Texas A&M University–Remote Sensing in Geosciences
• University of Arkansas–Control Point Documentation
• Western Oregon University–Image Registration

Brock Adam McCarty
Map Wizard
(720) 470-7988
brock@apollomapping.com

In August, we started a discussion on orthorectification in the Geospatial Frequently Asked Question (G-FAQ), and this month we conclude the two-part series. In the first part of the series, the focus was on the basics of orthorectification and how orthorectified data can be differentiated from georeferenced data. In this edition of the G-FAQ, we turn our attention to accuracy testing of orthorectified data. We also investigate RPC files which are often required to orthorectify imagery products.

As a quick reminder, we focus on these core questions in this two-part G-FAQ series:

What is the difference between georeferenced and orthorectified data? How is orthorectification completed and its accuracy tested? What are RPC files and how are they used in orthorectification?

In the August 2014 G-FAQ edition, we learned that georeferenced data has no accuracy guarantee. In order to have this assurance, imagery must be orthorectified; and to orthorectify imagery, you need a minimum of an elevation model and a camera model or rational polynomial coefficients (RPCs). In order to have the highest accuracy possible, you also need ground control points, a topic we will turn our attention to in the next G-FAQ series. For now, we can define ground control points as known locations on the surface of the planet with highly accurate XY (e.g. latitude and longitude) and Z (e.g. meters above sea level) survey coordinates.

Accuracy Testing of Orthorectified Imagery

Now let’s continue the discussion started last month with a look at accuracy testing of orthorectified imagery. In general, there are four factors which control the final accuracy of orthoimage. First, the image itself is a major contributing factor; and specifically, the off-nadir angle of the data and the topography it covers. Off-nadir is the angle the satellite was tilting when the imagery was collected, and for reference, zero degrees off-nadir would be pointing straight down at the ground. Imagery collected with a higher off-nadir (generally over 25 degrees) and/or over areas with lots of relief (such as mountains, hills and valleys) will be less accurate when orthorectified. Second, there is method used to orthorectify the imagery, and as was discussed last month, using a camera model in this process can result in a slightly more accurate final product. Third, the quality of the ground control used in orthorectification can impact accuracy. While we will not discuss control until next month, simply stated, the more accurate the ground control are, the more accurate the final orthoimage will be. Finally, there is the location and distribution of the ground control. If all of the control are clustered in the same small area, it can be accurate there but then far less accurate as you move away from this cluster. In general, the accuracy of orthoimage declines as you move away from the locations of ground control points (GCPs).

In order to test the accuracy of the orthoimagery you created, ground control points are required. Without ground control points, there is no way to assure accuracy in the final product so admittedly this is a bit of circular logic; and it can be rather frustrating when you lack this control. As such, for the next part of this discussion, let’s assume that you used ground control to create an orthoimage.

There are two ways to validate accuracy by using GCPs: the hold-out and the leave-one-out cross validation methods. In the hold-out method, accuracy is validated by taking a portion of the control you have, applying it to the imagery during orthorectification and then leaving out a subset to test the final accuracy once the ortho is complete. While this method has the advantage of being easy to compute, the disadvantage is that it can be unreliable as it depends on a set of control not used in the ortho process; and if there is a low number of GCPs for the project, these test points can be a poor, unrepresentative sample. The leave-one-out cross validation method is more complex to implement but it can have more reliable results. In this method, you test the accuracy of your orthoimage by subsetting out test control and control to be used in the ortho process, and then repeating this process multiple times–each time with a different subset of test control and control used to ortho.

Testing the accuracy of an orthorectified image is pretty straightforward once you determine the method to implement. Using the control you held out, the first step in accuracy testing is locating each test point in the orthoimagery. Once you have found the GCPs in your imagery, you will measure the straight line distance to its actual location on the ground. Each GCP’s actual location on the ground is determined by the XY (e.g. latitude and longitude; or northing and easting) coordinates recorded during the field survey. Repeat this process for each of your test points and record the measured distances in a spreadsheet.

Once you have the distances measured from the test GCPs to their actual locations on the ground, it is time to calculate an accuracy for your orthoimage. There are three common ways to report this accuracy: root mean square error (RMSE), circular error 90% (CE90%) and the US National Map Accuracy Standards (NMAS). Here is a brief description of each of these accuracy calculations:

A table showing the relationship between NMAS, CE90% and RMSE accuracy statements. You can see that as the map scale gets larger (e.g. moving from 1:12,000 to 1:4,800), the NMAS requires more accurate imagery.

• RMSE – calculated as the square root of the sum of the straight-line differences of the X and Y coordinates of test control points and their ‘real’ position on the ground. Basically, this is the average distance your orthoimagery is off from its ‘real position’ on the ground.
• CE90%–a distance that defines the radius of a circle whereby 90% of test control points will fall within their ‘real’ ground positions.
• NMAS –this final way of reporting accuracy is more of a standard then it is a way to calculate this value. Established in 1947 by the USGS, the NMAS assures orthorectified imagery used by the Federal government meets certain accuracy requirements as its scale changes. Take for example an orthoimage with a maximum zoom scale of 1:4,800, according to the NMAS, this data should have a 13.33-foot CE90%. So then, for any given map scale, there is an accuracy standard (often reported in CE90%) that this data must adhere too. For more information about NMAS, please refer to this previous edition of the G-FAQ.

Before we move on from this subtopic, a few words to the wise about accuracy testing. First, while it seems that accuracy is a well-defined topic, it is rather flexible so to speak. And I say this as depending on what control you decide to use for accuracy testing, the results can be radically different. If you select test control points that are all in flat areas, you will find higher accuracies; and the converse is the same for selecting test control on hills and/or mountains (i.e. the accuracy will be lower). Second, as a general rule of thumb, it is often possible to get imagery collected by the newer satellites, WorldView-1/2 and GeoEye-1, within 2 or 3 pixels of their ‘real’ ground positions, assuming good GCPs and an elevation model are used in the process; and for the remaining satellites, a final accuracy within 5 pixels is often achievable.

A Primer on Rational Polynomial Coefficients (RPCs)

In the final section of this two-part series, let’s take a look at RPC files and their importance in orthorectification. Broadly speaking, RPC files are a way to describe the position of satellite imagery on the ground in a standardized and effective manner. A RPC file contains two equations which relates image space (i.e. the line and column position of a pixel) to object space (i.e. its latitude and longitude, northing and easting, etc.). One equation computes line position to X and the other column position to Y, both equations build out XY positions from the upper-left corner of an image. The coefficients for each of these two equations is calculated by the imaging companies and is based on the satellite’s position and orientation when the data was collected as well as the proprietary rigorous camera model.

RPC files then are generic equations for all sensors that are easy for commercial remote sensing software developers to implement. In many cases, these software makers will substitute RPC files for use in orthorectification as opposed to gathering proprietary camera models from each of the imaging companies (which can be a time consuming process). While the goal is to incorporate all of the factors considered in the rigorous camera model into a RPC file, there is a small difference between the two. This can result in a slightly larger residual error in the final orthoimage for the version produced with RPC files. As a final note, each imaging company has a slightly different format for RPC files–for example, DigitalGlobe calls them RPB files while Airbus delivers them in XML format.

In the next G-FAQ series, we will turn our attention to ground control points which are the secret ingredients to making extremely accurate orthoimagery.

Do you have an idea for a future G-FAQ? If so, let me know by email at brock@apollomapping.com.

Find Out More About This Topic Here

• Center of Geotechnologies, Riccardo Slvini–QuickBird Stereophotogrammetry for Geological Mapping
• DIIAR, Maria Antonia Brovelli–Accuracy Assessment of High Resolution Satellite Imagery
• Michigan Tech University–Photogrammetric Control Surveying
• Penn State University–Orthorectification
• Rutgers University–Geometric Correction of Imagery
• University of Oregon–Geometric Rectification

Brock Adam McCarty
Map Wizard
(720) 470-7988
brock@apollomapping.com

In this month’s edition of the Geospatial Frequently Asked Question (G-FAQ), we turn our attention to the question of horizontal accuracy in high-resolution imagery products. While it seems like a topic that should be relatively straightforward, surprisingly it is wrought with complexities. Broadly speaking, orthorectification is the process of improving the horizontal accuracy of imagery; and as such, it will be the focus of this two-part series.

In this two-part G-FAQ series, we focus on this set of core questions:

What is the difference between georeferenced and orthorectified imagery? How is orthorectification completed and its accuracy tested? What are RPC files and how are they used in orthorectification?

Before we jump headlong into this two part series on orthorectification, let me frame the discussion a bit. First, my focus here is on high-resolution satellite imagery as that is where my knowledge base lies. While many of the principles discussed here would apply to aerial imagery as well, there are certainly topics relevant to aerial data and orthorectification that will not be covered. Second, my focus is on high resolution data and not on medium resolution data. This is done consciously as many medium resolution imagery products are simply too coarse to see features distinctly; and if you cannot see features (such as a sidewalk), then assessing the accuracy of an orthorectified dataset is impossible. And finally, the intent of this G-FAQ series is to address the basics of orthorectification so that our readers have an understanding of how an orthoimage is created and how its accuracy is assessed. I will not describe the mathematics behind orthorectification as admittedly this is well beyond my knowledge base.

Sources of Inaccuracies in Imagery

Many of our clients assume that high-resolution satellite imagery will be “accurate” to begin with, but this is not necessarily the case. To explore this topic, first we need to understand what the word, “accurate,” really means. In some cases, people use this term to refer to the alignment of the imagery they are purchasing with the spatial datasets they have in house. When this is the case, there is no way to assure accurate alignment without spatially registering the multiple layers to each other. Not only can the high resolution imagery we provide have accuracy errors, so too can the base layers a client has in house which can further accentuate the misalignment.

In other cases, the term accuracy can refer to how closely imagery aligns with its real position on the planet. While more modern satellites (such as GeoEye-1 and WorldView-2) have imagery that is closer to its actual position on the planet, the alignment is rarely, if ever, ‘perfect’ without additional processing of the data. These positional inaccuracies are caused by both internal and external factors. Internal factors are those caused by the imaging system itself, and include platform orientation and movement, optical and electrical aberrations and geometric characteristics. External factors will further compound internal ones and include the topography of the area imaged as well as atmospheric refraction. When taken together, internal and external factors can result in small or large positional inaccuracies; and further, accuracy will not be consistent from one image to the next even if it is collected by the same sensor, such as WorldView-2.

Georeferenced Versus Orthorectified Imagery

Now that we understand a bit about the sources of inaccurate data, let’s spend some time on three terms often used to describe satellite imagery: georeferenced, co-registered and orthorectified. Georeferencing is the process of projecting and thereby assigning coordinates (e.g. latitude and longitude) to an image. A georeferenced image has no accuracy guarantee; and while often times there is an accuracy statement for this type of data, it is a global average and not an assurance. In order to assure the horizontal accuracy of an image, it needs to be orthorectified.

Orthorectification creates a final product whereby each pixel in the image is depicted as if it were collected from directly overhead or as close to this as possible. In the graphic above, you can see a path through the forest going from the northwest to the southeast. On the left is the original image, and on the right is the orthorectified image. In the orthorectified version, you can see that the path is now nearly straight after the influence of topography has been removed from the image. (Graphic Credit: David DiBiase, Penn State University)

Orthorectification is the process of removing internal and external distortions to assign more accurate coordinates to the final image. The goal of orthorectification is to create a final product whereby every pixel in the image is depicted as if it were viewed at nadir (or directly overhead), thereby removing the affects of hills, valleys, etc. on the data. Once data has been orthorectified, you are able to compute distances, areas and directions more accurately from the imagery. As a side note, it is never possible to remove all of the distortion in an image as after all, we display imagery on a flat surface (e.g. a computer monitor or paper) while the world is obviously curved; or put another way, no orthorectified image will be 100% true to its real world position.

Co-registration is the process of matching one (or more) spatial layer(s) to another so they align as closely as possible. It is possible to co-register two or more image files (i.e. raster to raster) to each other, multiple images to multiple vectors (i.e. raster to vector) and even multiple vectors to vectors (i.e. vector to vector). Unless one of the spatial layers used in co-registration has a known accuracy and its position does not shift, there is no way to assure the accuracy of the final product(s) created by this process.

How to Create an Orthorectified Image

Generally speaking, an orthorectified image starts georeferenced. To orthorectify an image, you need at minimum these two items:

• An elevation model – this is a spatial layer that shows the topography of the ground under the imagery you plan to orthorectify. The preferred format of the elevation layer is a digital terrain model (DTM) whereby human-made features as well as vegetation and other surface features have been removed; accordingly, this is sometimes called a bare earth model.
• A camera model or rational polynomial coefficients (RPCs)–we will describe both of these items in more detail shortly, but simply stated, the camera model or RPCs describe the positional relationship of the imagery to the ground below when it was collected by the sensor.

In order to have a guaranteed accuracy for orthorectified imagery, ground control points (GCPs) are required. While we will discuss ground control in more detail in upcoming G-FAQs, for now let’s define them as known points on the surface of the planet that can be found in the imagery you plan to orthorectify. When an elevation model, a camera model/RPCs and ground control are taken together, orthorectified data can be extremely accurate–the higher the quality of the DEM and/or GCPs you use, the more accurate the final product can be.

For our visual-learning readers, orthorectification can be pictured in this fashion. High-resolution imagery is akin to a balloon that is stretched over the topography of the planet (i.e. the elevation model) and is tied down at multiple locations with known coordinates (i.e. GCPs). Once this stretching and tying-down process is completed, the balloon is now positioned accurately on the surface of our planet, or it has been orthorectified.

From the graphic and description above, it might be apparent that removing the influence of topography on imagery is one of the most important steps of orthorectification. The effect of topography is to tilt features in an image away from the center of the camera, and this is counter-acted by employing an elevation model in the orthorectification process. Accordingly, orthorectification has a more drastic impact on accuracy in areas of high relief. As a general rule of thumb, when orthorectifying high-resolution imagery, you should use a 10-meter elevation model or better; and in areas with extremely high relief, you might consider a higher resolution elevation model than this. Obviously, this is a general rule of thumb as it can be nearly impossible to find free 10-meter elevation models outside the USA; and creating them can be very costly and take weeks to months to complete.

As mentioned at the outset of this article, the mathematical models used to orthorectify imagery are beyond the scope of this G-FAQ. That said, it is useful to describe two of the more common methods employed in the orthorectification process from a high-level. The most common method is the black-box (or the analytical) model. This method does not look at the specifics of a sensor and/or the collection geometry of the imagery, rather it relies on RPC files (which we will address in more detail in the second part of this G-FAQ) for orthorectification. The advantage of the black-box method is that it is easy to implement as software developers do not have to gather proprietary information (i.e. the camera model) for each sensor.

The second methods for orthorectification are physical-based models which take into account a wide variety of factors influencing the acquisition of imagery. One of the most popular physical-based methods is referred to as the rigorous model or camera model. The rigorous or camera model is based on proprietary information about each sensor that can only be obtained from its owner; as such, many commercial software packages do not include this method. This model takes into account multiple factors not considered in the black-box model including the exact position of the satellite in space when the image was acquired, the sensor’s electronic and optical characteristics as well as atmospheric effects. The advantage of the rigorous model is improved accuracy of the orthorectified image, though my review of the available research suggests the impact is minimal. For example, Dial and Grodecki found less than a 0.1 pixel residual error difference between IKONOS imagery orthorectified by the black-box and rigorous models.

In the second part of this G-FAQ series, we will continue the discussion on orthorectification with a focus on accuracy testing and RPC files.

Do you have an idea for a future G-FAQ? If so, let me know by email at brock@apollomapping.com.

Find Out More About This Topic Here

• Center of Geotechnologies, Riccardo Slvini–QuickBird Stereophotogrammetry for Geological Mapping
• DIIAR, Maria Antonia Brovelli–Accuracy Assessment of High Resolution Satellite Imagery
• Michigan Tech University–Photogrammetric Control Surveying
• Penn State University–Orthorectification
• Rutgers University–Geometric Correction of Imagery
• University of Oregon–Geometric Rectification

Brock Adam McCarty
Map Wizard
(720) 470-7988
brock@apollomapping.com