'tis the season to discuss projections, so I thought I'd jump in.

I tried following the YT video about Finding NAIP Imagery with Viewer. In the video we are sent to the following data portal to get NAIP 4-channel imagery for agriculture infrared images.

https://prd-tnm.s3.amazonaws.com/index.html?prefix=StagedProducts/naip/

and for reference, the image I used is in the tx_2014/ folder at m_2909829_sw_14_1_20161010_20161129 in the NAIP Staged Products listing. It should show the San Antonio International Airport with easily recognizable runways.

That link might not work directly, but if you click the ../ link you'll go up the tree so you can come back down the tree to your location of interest. One thing you don't get from the portal is metadata for the .jp2 images posted in their staged products. When I searched out the projection every reference said to use UTM with the appropriate zone. For the SAT airport that would be UTM 14N. As the .jp2 data comes in, the projection (in red) says Pseudo Mercator. If you simply drag it to the map, the image appears about 6,930.030 meters north of the Google Earth location. When I assign the initial projection to UTM 14N to the image, it disappears from the map. Zooming to the location gives nothing. When I repair the initial projection using the Google Earth Pseudo Mercator projection, the image returns to its location 6,930.030 meters north of the airport.

I suspect the problem is with the image, but the disappearance when using UTM 14N puzzles me. Here is what I see with the raw image.

Still needing the image I switched over to the USGS Earth Explorer data portal. The data from there came in already projected as a geotif file (NAD 83 / UTM zone 14N (EPSG: 26914)). So while I do have what I want, what the heck is happening with the .jp2 data from the Staged Products server?? It seemed to work fine in the video.

Attachments:
NAIP Image Projection Issue.jpg

I didn't look at the file just yet, but:

Could it be that when you assigned UTM 14N to the image, you overrode the local offsets? You have to keep them. (If they are there, that is. If they are not = set to 0, that's a different issue, we should look into why they are not being read / are they actually in the file, etc.)

I took the defaults.

Attachments:
UTM 14 Local Offsets.jpg

I duplicated this behavior with your download link. I do notice that the pixel size is 1mpp and that your image is 8002 pixels high. If the image world information is stored by a system that defaults to a Northwest corner of the image to measure offset then this would explain the shift. To correct, start by subtracting the 8002 from the local offset Y-values in the metric editing dialog. That should bring everything into alignment.

Yes, that worked. New Y offset is 3,439,437.7843274563. Now if I can remember that for next time. Luckily it's documented right here on the forum.

It was more common of a problem 20+ years ago when world files were meager if extant at all. It was also a learning curve for me when really adopting Manifold 5 to work with our existing DOQs. It is good to keep in mind to check pixel size, image rect size and a slightly modified offset when running across files that *just don't work* i.e. legacy or customized types. Thankfully I haven't had that issue in quite a while with better supporting projection info.