Comparison of how a sandbar is viewed using various views of multispectral imagery. |
Tuesday, October 27, 2015
Lab 8 - Thermal & Multispectral Analysis
This week's lab focused on interpreting thermal imagery using ERDAS Imagine and ArcGIS. To this end we each had to select a unique feature on a multispectral composite image of the Pensacola, Florida and analyze how it appears in various wavelengths.
The wavy appearance of the sandbars along the northern shorelines caught my eye, so I'd decided to focus on how these appear within various wavelengths. While the sandbars are visible in just about all of the combined multispectral imagery, when viewed within separate bands it was almost impossible to see. The contrast, or brightness values, had to be altered in most cases. The only individual bands that the sandbar was semi-visible in was within Band 4 (a near infrared band) and Band 6 (a thermal infrared band).
Monday, October 26, 2015
Lab 9 - Accuracy of DEMs
This week we analyzed the accuracy of DEMs (Digital Elevation Models). This particular lab has built upon concepts that were covered in Labs 1 - 3, and heralded the return of RMSEs (root mean square error), percentile calculations, and Excel spreadsheets.
Determining the accuracy of elevation data is remarkably similar to determining the accuracy between x, y coordinates. Essentially, one needs a series of sample points from the original data set (preferably at least 20 per land cover class type) and a set of reference data. The reference data should be of a higher quality than the source data. In the case of elevation data this usually would be the elevation data collected from a sub-meter GPS during the initial data capture (such as with LIDAR). The differences between the source data and the reference data sets are then calculated. Statistics such as RMSE, 68th percentile, and 95th percentile are then calculated.
To illustrate this, the first portion of our lab compared reference points and source points for LIDAR data taken within North Carolina. The data was sub-divided into 5 general land cover types; each land cover type had test points well in excess of the recommended 20 sample points. After calculating the average RMSE, 68th percentile, and 95th percentile statistics for each land cover type tested, the data was then viewed on a scatter plot graph to see at a glance where obvious outliers in the data are, as well as areas of potential bias.
What I had found was that the differences between the reference and source elevations were relatively similar (from between -0.2 to 0.4 m). There was one obvious outlier, which represented a possible error during data collection. There was also a slight bias in the DEM, with the DEM underestimating elevation values. I've included a graph showing this data; the potential bias is visible from -0.3 to -0.7 m on the graph.
Determining the accuracy of elevation data is remarkably similar to determining the accuracy between x, y coordinates. Essentially, one needs a series of sample points from the original data set (preferably at least 20 per land cover class type) and a set of reference data. The reference data should be of a higher quality than the source data. In the case of elevation data this usually would be the elevation data collected from a sub-meter GPS during the initial data capture (such as with LIDAR). The differences between the source data and the reference data sets are then calculated. Statistics such as RMSE, 68th percentile, and 95th percentile are then calculated.
To illustrate this, the first portion of our lab compared reference points and source points for LIDAR data taken within North Carolina. The data was sub-divided into 5 general land cover types; each land cover type had test points well in excess of the recommended 20 sample points. After calculating the average RMSE, 68th percentile, and 95th percentile statistics for each land cover type tested, the data was then viewed on a scatter plot graph to see at a glance where obvious outliers in the data are, as well as areas of potential bias.
What I had found was that the differences between the reference and source elevations were relatively similar (from between -0.2 to 0.4 m). There was one obvious outlier, which represented a possible error during data collection. There was also a slight bias in the DEM, with the DEM underestimating elevation values. I've included a graph showing this data; the potential bias is visible from -0.3 to -0.7 m on the graph.
Graph of differences between the source data and reference data; difference values are in meters. |
Wednesday, October 21, 2015
Lab 7 - Multispectral Analysis
This week's lab focused on identification of features using various bands of satellite imagery. The maps below show the results of a seek-and-find type exercise, using spikes in pixel values between image bands as our guide to find the required features.
Map 1. The darkness of the pixel values representing open water were offset by using false natural color. |
Map 2. The brightness of the snow pack is offset by the surrounding landscape, shown in false color infra-red. |
Map 3. The variations within the shallow water are visible by setting the color bands to a TM Bathymetry setting. |
Monday, October 19, 2015
Lab 8 - Surface Interpolation
This week we covered various interpolation methods, as well as the best uses for each type of interpolator.
Part of the lab involved comparing two DEMs that we created from elevation point data. The two interpolation methods used were IDW (Inverse Distance Weighted) and Spline (regularized). To compare the differences between the two methods the Raster Calculator tool was used to subtract the elevation values between the two DEM grids. A map of the final result is shown below.
Part of the lab involved comparing two DEMs that we created from elevation point data. The two interpolation methods used were IDW (Inverse Distance Weighted) and Spline (regularized). To compare the differences between the two methods the Raster Calculator tool was used to subtract the elevation values between the two DEM grids. A map of the final result is shown below.
Map showing the differences between two DEM grids. |
Thursday, October 15, 2015
Lab 6 - Spatial Enhancements
View of the spatially enhanced image. |
The enhancements were applied using both the ERDAS Imagine software and ArcGIS. The processing began with ERDAS Imagine by applying a Fourier transformation with a low pass filter. Then the image was further processed by applying a 3x3 sharpening effect (the 3x3 refers to the number of cells used as the kernel for the enhancements).
The image was then opened in ArcGIS, since this program has a Focal Statistics tool (and ERDAS Imagine doesn't quite have these statistics in its arsenal of enhancements). After setting the Focal Statistics tool to run a rectangular 3x3 mean pass the image was considered to be ready for the final map layout.
While the diagonal lines haven't disappeared completely at least it is now possible to figure out what the features in the image are. Apparently it is possible to remove those diagonal lines, but that requires some additional (advanced) techniques... trying to get the Fourier transformation correct for this exercise was difficult as it was.
Monday, October 12, 2015
Lab 7 - TINs and DEMs
This week's lab explored the differences between a TIN surface and a DEM.
TIN stands for 'Triangulated Irregular Network' and DEM stands for 'Digital Elevation Model'. Both surfaces represent landforms based on elevation data, and both can be used to show slope, aspect, and contours. A major difference between the two is the file type - a TIN surface is vector based whereas a DEM is raster based.
A bonus to a TIN surface is that aspect, contours, and slope can all be depicted and stored within the same file. A DEM raster cannot do this - different files would need to be created to show slope, aspect, and contours... and this could potentially involve multiple steps (for example, a slope raster may need to be converted to polygons if one wanted to show it as vector data).
Another bonus to a TIN surface is that breaklines (essentially, a linear feature) can be used to modify the original topography. This is not possible with a DEM, thus making the TIN surface ideal for engineering applications... or detailed archaeological site maps.
Why aren't we using more TIN surfaces if they're so great? Well, they require a lot of computer memory, and therefore shouldn't be larger than 1,000,000 nodes. That may sound like a lot, but these things tend to be quite detailed and so can reach that threshold easily. TINs also are not the best surfaces to use when one wants to model continuous data over large areas - that is where DEMs shine.
TIN stands for 'Triangulated Irregular Network' and DEM stands for 'Digital Elevation Model'. Both surfaces represent landforms based on elevation data, and both can be used to show slope, aspect, and contours. A major difference between the two is the file type - a TIN surface is vector based whereas a DEM is raster based.
Detail view of a TIN surface, showing contours, nodes, and edges. |
A bonus to a TIN surface is that aspect, contours, and slope can all be depicted and stored within the same file. A DEM raster cannot do this - different files would need to be created to show slope, aspect, and contours... and this could potentially involve multiple steps (for example, a slope raster may need to be converted to polygons if one wanted to show it as vector data).
Another bonus to a TIN surface is that breaklines (essentially, a linear feature) can be used to modify the original topography. This is not possible with a DEM, thus making the TIN surface ideal for engineering applications... or detailed archaeological site maps.
Why aren't we using more TIN surfaces if they're so great? Well, they require a lot of computer memory, and therefore shouldn't be larger than 1,000,000 nodes. That may sound like a lot, but these things tend to be quite detailed and so can reach that threshold easily. TINs also are not the best surfaces to use when one wants to model continuous data over large areas - that is where DEMs shine.
Monday, October 5, 2015
Lab 6 - Location-Allocation Modeling
This week's lab saw us using Network Analyst to perform a basic location-allocation analysis. The goal was to show where change may be needed in a fictional company's distribution center service areas. Since the distribution centers were built during the company's national growth, the areas being served may not actually be the best fit in terms of time and resources. The service areas, or market areas, were reassessed using the location-allocation function.
The analysis also utilized advanced settings and set the analysis type to minimize impedance. This meant that it solves what ESRI calls the 'warehouse location' problem - it minimized all of the total impedances set into an analysis. Our impedances utilized a roads network, which allowed U-turns and had the origination of the routes be at the facility (as opposed to the demand points - a.k.a. customers).
If you were wondering, an impedance is a cost built into the analysis - meaning something the algorithm has to factor in. Since the location-allocation analysis is built into the Network Analyst extension, this means that the algorithm essentially calculates the best routes from a facility to a customer. No impedance cut-off was set (which usually refers to a set mileage from a facility or a drive time), so theoretically a customer located hundreds of miles away from a distribution center could be included within the market area for that center... provided that no other facility was located closer.
Comparison of the market areas before and after completing the location-allocation analysis. |
Technical Notes
The location-allocation analysis was run with the distribution centers as a required facility type. This meant that the solver had to choose all 22 of the distribution centers when computing the final service areas.The analysis also utilized advanced settings and set the analysis type to minimize impedance. This meant that it solves what ESRI calls the 'warehouse location' problem - it minimized all of the total impedances set into an analysis. Our impedances utilized a roads network, which allowed U-turns and had the origination of the routes be at the facility (as opposed to the demand points - a.k.a. customers).
If you were wondering, an impedance is a cost built into the analysis - meaning something the algorithm has to factor in. Since the location-allocation analysis is built into the Network Analyst extension, this means that the algorithm essentially calculates the best routes from a facility to a customer. No impedance cut-off was set (which usually refers to a set mileage from a facility or a drive time), so theoretically a customer located hundreds of miles away from a distribution center could be included within the market area for that center... provided that no other facility was located closer.
Subscribe to:
Posts (Atom)