The shape files (try them, you'll see) just show what the region is that the image covers. All you care about for imagery are the .tif files. This is what I did: 1. Visit https://earthexplorer.usgs.gov 2. Pause to curse them for requiring a login. Logged in. 3. In the Data Sets tab, expand the Aerial Imagery hierarchy and check the High Resolution Orthoimagery box. 4. In the Search Criteria tab, click Use Map and then draw a box over the center of Glen Ellen, right about where Arnold Dr intersects O'Donnell Ln. 5. Press results. 6. Download each of the resulting four .zip files: 2538643_10SEH407457.zip 2543153_10SEH415457.zip 3664742_SOCO0028194.zip 3666266_SOCO0028193.zip Setting aside the massive amount of bureaucratic stuff in the zip files (pdfs, zipfiles, etc.) other than imagery, the first two unzip to 95MB .tif files shot in 2011 that are accompanied by .tfw and .tif.xml files. The second two unzip into 70 mb .tif files shot in 2013. As is often the case with images, using these .tif files is all about getting the right projection assigned. I followed the procedure given in the Example: Merge Images topic. You can download Viewer for free and follow along. 9 is so much better at images than 8 that I don't use 8 for images anymore. When you follow that procedure, the first two tifs import and georegister perfectly. They are plain .tif files accompanied by "world" files, which 9 reads perfectly. You can also use Merge Images to merge them into a single image perfectly. The second two tifs seem to be intended to be geotiffs, but imported into 9 the projection assigned is incorrect: it ends up being lambert conformal conic, not stateplane nad83 california 2 as the metadata on the explorer site says it is. Assign that projection manually and the images appear near Glen Ellen, but stacked on top of each other. That usually indicates an offset problem. In theory you could fix that by manually calculating and then assigning offsets using the metadata published. The right solution is for 9 to read the geotiff and extract all that. 9 normally reads geotiffs perfectly so it is highly unusual to encounter correctly-written geotiffs from which the coordinate system info is not automatically and perfectly extracted by 9. For some reason, that is what is going on here. The usual problem in such cases is the file is doing something wrong. That happens even with USGS. But it also happens (less and less frequently, but still, it happens) that 9 is making a mistake. Sometimes it is just a gray area issue. We have to sort out which of those options is going on in this case and make whatever adjustment is necessary. ESRI's ArcEarth Explorer reads them OK, so Manifold no doubt can make whatever adjustment is necessary. I've written up a bug report and have sent it in. So... for now, use the 2011 series, and expect the 2013 series to be supported sometime in the next few weeks.
|