Revisiting this one more time, here is a quick-and-dirty Python script that automates the kludge for a whole directory full of TIFFs.
import arcpy, osfrom arcpy import env
# Script argumentsinputWorkspace = arcpy.GetParameterAsText(0)
# Set workspaceenv.workspace = inputWorkspace
# Arbitrary one point file parked where Python script is. Mine contains "24.896918 18.439029 24.896918 18.439029"# Could create this on the fly, then delete it at the end.regPtsFile = "fixregistration.txt"
# Loop through rastersfor inRaster in arcpy.ListRasters(): # Update georeferencing arbitrarily. arcpy.RegisterRaster_management(inRaster, "REGISTER", "#", regPtsFile, "ADJUST", "#") # Delete the created xml file. tifAuxXmlFile = os.path.join(inputWorkspace, inRaster + ".aux.xml") if os.path.isfile(tifAuxXmlFile): os.remove(tifAuxXmlFile) else: # If it fails, inform the user. print("Error: %s file not found" % tifAuxXmlFile)
To resuscitate an old thread, I've been floating between Desktop 10.7.1 and Desktop 10.8.1 and was still encountering the same issue with "Update Georeferencing" when working with TIFFs.
However, I was poking around in the Customize --> ArcMap Options --> Raster --> Raster Dataset settings and also unchecked Create Tiled TIFF. Keeping both Use world file to define the coordinates of the raster and Create Tiled TIFF unchecked seems to create some stability when using "Update Georeferencing" for TIFFs.
related article:
Problem: Using Update Georeference in ArcMap moves a raster image to a different location
I have encountered this problem in the past, and have just encountered it again using 10.5.1.) I finally decided to give it a good hard look and try to understand it. I believe I can explain what is going on, and I have a kludge to get around it.
Cutting to the chase for those who want the kludge:1. Add the image to the MXD.2. Add any single arbitrary georeferencing point to the link table.3. Georeferencing > Update Georeferencing4. Remove the image from the MXD.5. Delete the aux.xml file associated with the image.6. Add the image. (It will pop in at a somewhat different location.)7. Georeference as usual.
(This slightly messes up my workflow, as I normally Build Pyramids and Statistics for all images, and deleting the aux.xml file deletes the statistics, but these can be built later.)
OBSERVATIONS AND EXPLANATION:
In my current project, I am working in NAD 1983 BC Albers (WKID 102190), which has a linear unit of meters. Choosing one of my problem images and using ImageMagick identify, the TIFF has tags (among others): Geometry=16853x10772+0+0, Resolution=300x300, units=PixelsPerInch, Print size=56.1767x35.9067", Orientation=TopLeft.
When I insert a problem image and mouse over the approximate top left and bottom right corners the projected location reads as approximately 0,36 and 56,0 meters. (The image is inserted into the MXD with no projection information. However, when it is inserted it still needs to be mapped to some location in the CRS [i.e, to zoom to the image it cannot be outside the space mapped by the CRS]. The mapping apparently is transforming 300 pixels per inch to 300 pixels per meter, hence 0,36 and 56,0, ballpark original image locations in inches.)
If I georeference points close to these corners to known locations, the coordinate pairs in the link table are:
1.351994 34.575973 952183.094839 856847.71565851.362419 1.250201 1034479.259431 801983.605930
(As it happens, the second pair in each case are absolute, known coordinates that are provided by snapping to a grid.)
When I update the georeferencing the TIFF file size increases by around 170KB. Arc is writing something to it. Whatever it is is not seen in the tags ImageMagick reads -- they look exactly the same. However, something in that 170KB makes Arc add the image in a different location, where the approximate corners are 0,0 and 56,-36 meters. Presumably this is the correct location, trusting that Orientation=TopLeft means that 0,0 should be the top left corner and that Arc is ignoring that the mapping should be pixels per inch instead of pixels per meter. If I georeference this with the two corners my coordinate pairs in the link table are:
0.937064 -0.727514 952183.094839 911711.82538750.812487 -34.239148 1034479.259431 856847.715658
And that works fine. (Of course, I'm simplifying and using only two points when I'd normally use more.)
I note that looking at the (incorrect) first aux.xml and (correct) second aux.xml that they have different values for <XOrigin>, <YOrigin>, and <XYScale>.
I'd be happy if ESRI would look into this. The details above should be enough for a programmer to determine why images are being added apparently using the wrong corner as the origin.
Thanks, James. I don't see "Auto Display". I'm on 10.5.1, do you think it's the same as "Auto Adjust" in the Georeferencing dropdown? It's the only toggleable option.
John on 10.5.1
My solution is similar. After adding the .TIF raster file to the mxd, I toggle 'Auto Display' on/off > select 'Update Georeferencing' > add control points > select 'Update Georeferencing' a second time and the file sticks. This method has been successful thus far for me. Another method I found to work is assigning the coordinate system prior to adding the unreferenced .TIF raster file to the mxd. Using this method I can simply add the control points, select 'Update Georeferencing' and the file sticks.
I don't understand why either method works but after much frustration I can finally georeference files with relative ease once again.
Ricki, that is SO not fair. Here's what I'm getting:
I've set "build pyramids" by default (no prompt). I add a new TIFF, select it in the Georeferencing window, fit to display, nail it down with two control points, Update Display, Update Georeferencing, and ZOOM! A hundred feet in any direction, but here's the tricky part:
I remove the TIFF, then go to the folder and delete the three new TIFF support files created from georeferencing in order to start over. I do exactly the same steps as before, but this time it sticks! I did this exact process with eleven TIFFs yesterday without fail. The final one I didn't even bother with control points, just Fit > Update > Update > Remove > Delete, then start over, and it stuck.
It's kind of maddening, but as long as there's one reliable, consistent process I'll take it!
John,
The same thing happened to me at first, then I tried doing it by building pyramids first (the workflow which I had previously abandoned) and the "Update Display" and "Update Georeferencing" has worked ever since.
ricki on 10.5.1
"Update Display" then "Update Georeferencing" worked immediately after I read it, then I imported my next TIFF (with no pyramids) and tried again. Update Display looked good, then Update Georeferencing kicked it a hundred feet west.
I'm almost glad this failed since this particular project is for live review, and the non-pyramid drawings just ooze down the screen like molasses, so I really didn't want that to be the solution.
I fear without universal consistency we have no way of knowing what's actually working and what's just luck, but as another data point for troubleshooting, I'll add that I do have several large TIFFs crammed into this one data frame.
Yeah, same here: Pro had the same, shifting problem. So I just geo-reference in ArcMap since I know how to make it work there (on my machine). I plan on upgrading my computer soon, and I suspect it may change my strategy.
Wow, it's amazing the variety of solutions that have worked, and also not worked, for people having the same problem!
I have had this issue since I started doing georeferencing work in August, 2017 using ArcMap 10.5. About 70% of the time, when I hit "update georeferencing", the image would shift so that it would be right next to the georeferenced position. The inconsistency made it even more frustrating!
I looked at this thread back in 2017 and tried the solutions that people had suggested, but didn't have any real luck. My best option seemed to be to rectify everything just in case it didn't work, and then if it did, I deleted the rectified image from our server since the rectified images were much larger files.
However, Kyle Bearden's suggestion seemed to help me. So far, clicking "update display" before "update georeferencing" seems to be helping keep things in place. Not sure why this is, but I really appreciate the solution. Thank you!!Best of luck to anyone else out there having this issue!(BTW, I tried georeferencing in Pro as a way to familiarize myself with the software and also hopefully avoid the issue, but my experience was that the georeferencing there was even more broken than in ArcMap. Not sure if anyone else has had the same type of experience).
Kyle,
Thanks so much for this solution. I have been using it for a few weeks and it works great. Thanks again!
I've had this same problem. What seems to be working for me is to hit "update display" first, then hit "update georeferencing"
One other thing I noticed - and I have no idea whether it has anything to do with the problem - is that I started having this problem almost immediately (if not immediately) after I upgraded to 10.5.1. It was also not long after I started using Pro in a big way (although this problem is in Desktop). Any ideas?
Upon further testing and after conferring with some other nearby agencies that use GIS to georeference plan sheets, we determined that part of the problem MIGHT have been that these TIFFs were stored on a network drive. When the files that were not retaining the georeferencing were pulled to the local machine, the georeferencing stuck. That said, we then had to have our end users pull those files local for the georeferencing to display correctly, so this was not the ultimate workaround, just a workaround. Some files did not have this problem even when stored on the network drive, so even this workaround was a bit random. Also, we did try to georeference plan sheets in Pro, and found that when we "saved" the georeferencing, the plan sheet would move off where we told it to be every time. We tried with multiple transformation types. We never did get it to stick. All in all this has been a significant Esri fail.
I am having the same problem with my larger rasters.tiff images with 10.5
I have tried the above mentioned solutions, currently trying the Rectify option - which is not optimal for me since it takes longer than I need it to.
I would love a solution ESRI (and please do not tell me to move to Pro).
Just some more two cents: what seems to work best for me is to load only one image at a time. If I have more than one image to geo-reference in the data frame, then which ever one I just to geo-reference goes wonky when I try to update. But if I only have one image to geo-reference in the data frame, all goes well.
I know, that seems totally random, but it's what I've found works for my system (because rectifying takes way way too long). I hope that helps someone.
Kelly,
I experimented and the only thing that I found that worked was NOT building pyramids when I bring the data in.
This allowed me to georeference my image without any problem. The redraw was just a little slower, but I can live with that.
Rick Ingle, GISP, MCF
Senior Systems Analyst - GIS
Manatee County Public Safety / 911
2101 47th Ter E
Bradenton, FL 34203
Lat. 27d27'28.77"N Long. -82d32'12.14"W
941.748.4501 x7889
rick.ingle@mymanatee.org
http://www.mymanatee.org
This started happening to me too on June 13, 2018. I am using 10.3. Prior to June 14 I had no problem. In ArcMap Options > Raster > Raster Dataset the box for "Use world file to define..." was already uncheked. Rechecking it did not resolve the issue. I'm in the middle of an enormous georeferencing/digitization effort and was hoping to find a resolution here. I am suspicious given that someone else started having this problem within hours of myself.
I am having the same problem with 10.5.1 but have tried everything suggested and nothing has fixed the problem. Any other ideas?
Awesome. Same issue in Arcmap 10.6 and it was resolved with your suggestion!
I have found another workaround that's not posted here, maybe it helps someone. When I georeference a tiff and click update georeferencing on the toolbar a .tfwx worldfile is created, but the image appears back in it's original location. If I then change the file extension .tfwx to .tfw (the old worldfile extension) and re-add the tiff to the map it will be in the correct location.
I have no idea why this works, but honestly by the time I figured it out I didn't care anymore. Good luck!
Hi Stef,
I talked to an ESRI analyst at the UC. Though she didn't have a quick and hard solution for us, she did offer some good advice!
Once you have created all your link points, before hitting Update Georeferencing, save the link table. That way, if it doesn't work, at least you can re-load the links when you go back to try it again. She also said that what is causing it is probably some errant pair of points (or link). She said to really pay attention to what is on the link table. If there's a row that's amiss or has an usually high RMS, delete it, then try to update.
If all else fails, just rectify.
Im having the exact same issue Petronila, only started at 10.5 and my "Use world file to define the coordinates of the raster" is already unchecked.
I just started having this problem. I've been using ArcMap since...since...well, since it was ArcView.
Anyway, I've never had a problem with the georeferencing tool, but now I am getting this exact problem running 10.5. It just started doing it yesterday. Completely out of the blue. I haven't changed any setting (that I know of). And the option noted above by @Brandt Meyer IS unchecked.
Any other ideas?
This was the solution to the same issue I suddenly started having with 10.3.1 yesterday. I followed your instructions and I was finally able to update georeferencing again. Thank you for documenting!
Thanks Brandt, you saved my day! This option does exatly the opposite to what was intended!
To anyone else who is having this issue...
I had the same problem in Arc 10.2- I would click "Update Georeferencing", the software would "think" for a few seconds, act as if it completed the task, but then the raster would reload to it's original position (in my case at 0,0). There was no obvious update to the raster file, and all of the linked points in the georeferencing window would disappear, as if they had been applied and then cleared.
The specific setting that I changed to correct this was
Customize > ArcMap Options > Raster > Raster Dataset >
and Un-check "Use world file to define the coordinates of the raster"
As far as I can tell, that setting being checked prevented any georeferencing information being written to the file at all, i.e. not to a world file, the aux file, or the tiff itself.
I suspect that this is not the intended behavior, and is a hassle for me, since most of our company imagery uses world files for georeferencing.
Hope this helps someone down the road.
サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
