Aerial Tile Alignment Issues

[JeffDavis7]

Hello,

I have eleven aerial tiles (TIF) that I will be using to create a mosaic.

Unfortunately, 2 out of the 11 tiles are severely lacking in accurate extent and void of spatial reference information.

I have tried modifying the coordinate systems of these tiles using ArcCatalog(RC-Properties/Edit Spatial Reference) to match one of the defined tiles to no avail.

I have attached screenshots corresponding to the properties section for the rasters in question - please see 13-1996TIF.jpg and 18-1996TIF.jpg.  The other attachment, 12-1996TIF.jpg is an example of one of the tiles that does come in successfully.  The extents of both 13-1996.TIF and 18-1996.TIF are drastically different than the other tiles as evident by the example in 12-1996.TIF.  I can't help but think this is the key but I do not know how to approach the issue if it is the problem.

I should also note that 12-1996.TIF is the northern neighbor of tile 13-1996.TIF while 18-1996.TIF is its eastern one.

Thank you and I hope you can help.

[GuenterDoerffel]

Hi Jeff,

in case of tiled data where many tiles work just fine and (as you describe) two dont, a little bit of logic might help, as they are usually just shifted a bit, but the remaining parameters are the same (like pixel size and hopefully no rotation angles involved):
Take one of the properly located neighboring tiles and check if there is an external world file (*.tfw; Same name, different extension) for it. If not, use the GP Tool "Export Raster World File". Now you can copy/rename the world file to match the name of your misaligned tile(s) and adjust the values in there with any Text editor. See help to learn about world-files if you dont know how they are structured. Also set the Spatial reference of the tiles to the same SRS as the ones that work. If you have problems, let me know

Guenter

[JeffDavis7]

Hi Guenter,

Thank you for responding to my post.

I've opened the world files in Notepad for three surrounding, properly placed tiles, and three tiles that do not come in appropriately (two has increased to three).  Please see screen capture "1996 TIF World Files".  The new TIF added to the mix has an Orthographic spatial reference listed in the properties (14TFW).  All of these tif files, both proper and improperly placed, have world files attached.

In looking at these world files I see how the C,F translation terms entries account for the x,y coordinates.  Could you please tell me what should I be looking at for issues given these examples?

Before posting this question, I used ArcCatalog to set the Spatial Reference of the unknowns with the properly placed tiles and unfortunately nothing changed.

I also tried to define the projection of 13 and 18 as Orthographic (like 14) and converting to the properly placed coordinate system as well.  That didn't work either.

[GuenterDoerffel]

Hi Jeff,

I still assume you use Map/Catalog. So that is what I reference:

Your world files indicate, that they had been created using the same spatial reference for all files. Though in scientific notation in your screenshot, the "domains" of the values can easily be identified as identical: One example:
As you mentioned that 18 is the easterly neighbor of 13:
The pixel size of both is 2(here I assume feet) - 13 has 2750 rows and columns, so the extent is 5500 feet, the coordinates in the world file for y are 5330 feet apart ... close match, maybe they overlap? - at least this is reasonable
Looking at your screenshots of the Raster properties in the first post, the same thing basically applies: 18 and 13 share the same "coordinate space" - and the corresponding pixel size (again, I assume feet) but lack a projection.
12 has a projection - units meter (2 feet are 0.609 meters!) - but ... the coordinates in 13 and 18 (and 12) are not the ones in the world-files , so "something" has happened to them inbetween. You mention different projections ...

ArcMap will not use the Information in the world files, whenever there is header information - which your screenshots prove (see here: World files for raster datasets—Help | ArcGIS for Desktop ). Thats why it all gets mixed up. If you set ArcMap to use the world files (Customize - ArcMap Options - Raster Dataset "use world file ...") , I'd assume your images line up nicely - but you'd need to know what the projection is. And it is for sure one based on feet ... 

If I mimic the files using the info you provided and basing the location on the world files - I get this (12=red, 13=green,18=blue):

So to sum up: Projections are mixed up and read from the headers/aux.files ... your "unified" information seems to be in the world files - thats the way to fix it - if you know the projection stored there. Afterwards you can project them ina similar way to other SRS. Did that help?

Guenter

[JeffDavis7]

Hi Guenter,

Thank you for sticking with me on this issue.  I really appreciate it!

I thought I had a pretty good handle on coordinate systems and transformations until this episode.  You are definitely helping me understand the situation a little better.  I do see now what you are referring to in the Cell Size being characterized in a "feet" manner in 13 and 18 versus the "meter" manner in 12.  That does appear to be the key.  In applying your suggestions, I started a new project file and modified the ArcMap Raster options as you suggested.  In order I added the following TIF files --- 18, 13, 12 & 14.  You are indeed correct they all come in nicely together and when you right click on the Layers to access Data Frame Properties the Coordinate System tab indicates No Coordinate System.  So in essence I can get them to display by adding the ones with issues first and have 12 reproject on the file to match.  That's a definite improvement.

My reason for all of this is to create a mosaic of the 1996 tiles and of course they all need to be in the same coordinate system to perform that task.

So in essence, if I understand you correctly, I need to start experimenting with defining the coordinate systems for 13 and 18 based on feet and then reprojecting to the coordinate system of my other tiles.  Is that right?

As a side note, I had previously mentioned I found 14 did not match the other tiles as well but I was able to successfully bring it in with 13 and 18.  It has a Spatial Extent labeled as Orthographic in its properties.  I have tried to reproject this to the successful tiles coordinate system without success.  Any ideas on that one?

[GuenterDoerffel]

Hi Jeff, 

pleasure.
You are NEARLY right in what I would try to do 🙂 
The key is to find out what the projection is, that the World-Files refer to. It cant be the Orthographic/Geographic - as this has degrees as units, neither meter nor feet. It cant be the StatePlane you list for the 12-tile, values in coordinates dont match and the unit there is meters. So if you search in ArcGIS SRS in Feet you get a huge list of option ... 

Once you know which one it is, you could get rid of all aux.xml files that might reference wrong values, make ArcMap use the world-files and then use the "Define Projection" Tool to assign the right projection. The result would be a "future proof" solution with everything clearly defined AND in sync (data and world files)

If you want to just "fix" just the corrupted ones, an alternative would be to just georeference them with a few control points  ... 

Guenter

[JeffDavis7]

Hi Guenter,

Thank you for getting me on the right track.  I was able to achieve 90% success on my project.

I ended up taking tiles 13 and 18 and assigning a projection of Vertical Perspective (world) which successfully allowed me to project them both to my State Plane Coordinate System. 

I have one stubborn tile remaining that refuses to go quietly.  Tile 14, instead of being listed as Undefined, is actually populated with "Orthographic" in the Spatial Extent.  I've attempted to re-define it as Vertical Perspective (world) and went through the same motions as 13 and 18 but it did not cooperate.  I tried re-projecting using Orthographic as the starting point and my State Plane as the end point and it too failed.

This one has me mystified.